Thread
-
PL code and fmgr_addr
Bruce Momjian <maillist@candle.pha.pa.us> — 1998-02-03T19:57:46Z
Another problem I found with the PL code was that it took the fmgr() macro, and made it call a function call to fmgr_addr, which just killed performance. I made fmgr_addr() a macro too. -- Bruce Momjian maillist@candle.pha.pa.us
-
Re: [HACKERS] PL code and fmgr_addr
Jan Wieck <jwieck@debis.com> — 1998-02-05T15:55:16Z
> > Another problem I found with the PL code was that it took the fmgr() > macro, and made it call a function call to fmgr_addr, which just killed > performance. > > I made fmgr_addr() a macro too. > > -- > Bruce Momjian > maillist@candle.pha.pa.us > > Just to let you know - after fixing some other problems caused by the bpchar trouble my PLtcl tests went through again. Looks the macroization is O.K. Until later, Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] PL code and fmgr_addr
Marc G. Fournier <scrappy@hub.org> — 1998-02-05T15:57:45Z
On Thu, 5 Feb 1998, Jan Wieck wrote: > > > > Another problem I found with the PL code was that it took the fmgr() > > macro, and made it call a function call to fmgr_addr, which just killed > > performance. > > > > I made fmgr_addr() a macro too. > > > > -- > > Bruce Momjian > > maillist@candle.pha.pa.us > > > > > > Just to let you know - after fixing some other problems > caused by the bpchar trouble my PLtcl tests went through > again. Looks the macroization is O.K. Do we have regression tests for this?
-
Re: [HACKERS] PL code and fmgr_addr
Jan Wieck <jwieck@debis.com> — 1998-02-05T16:13:36Z
> > On Thu, 5 Feb 1998, Jan Wieck wrote: > > > > > > > Another problem I found with the PL code was that it took the fmgr() > > > macro, and made it call a function call to fmgr_addr, which just killed > > > performance. > > > > > > I made fmgr_addr() a macro too. > > > > > > -- > > > Bruce Momjian > > > maillist@candle.pha.pa.us > > > > > > > > > > Just to let you know - after fixing some other problems > > caused by the bpchar trouble my PLtcl tests went through > > again. Looks the macroization is O.K. > > Do we have regression tests for this? > > > No - since PLtcl isn't part of the distribution up to now. And I think that even if we include PLtcl into the dist we shouldn't include it into the regression tests because building PLtcl requires a Tcl installation (at least the libtcl??.so and tclConfig.sh). But it would be O.K. for me to include the PLtcl to the contrib directory and setup a separate test suite there. Until later, Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) # -
Re: [HACKERS] PL code and fmgr_addr
Marc G. Fournier <scrappy@hub.org> — 1998-02-05T23:03:09Z
On Thu, 5 Feb 1998, Jan Wieck wrote: > > > > On Thu, 5 Feb 1998, Jan Wieck wrote: > > > > > > > > > > Another problem I found with the PL code was that it took the fmgr() > > > > macro, and made it call a function call to fmgr_addr, which just killed > > > > performance. > > > > > > > > I made fmgr_addr() a macro too. > > > > > > > > -- > > > > Bruce Momjian > > > > maillist@candle.pha.pa.us > > > > > > > > > > > > > > Just to let you know - after fixing some other problems > > > caused by the bpchar trouble my PLtcl tests went through > > > again. Looks the macroization is O.K. > > > > Do we have regression tests for this? > > > > > > > > No - since PLtcl isn't part of the distribution up to now. > And I think that even if we include PLtcl into the dist we > shouldn't include it into the regression tests because > building PLtcl requires a Tcl installation (at least the > libtcl??.so and tclConfig.sh). > > But it would be O.K. for me to include the PLtcl to the > contrib directory and setup a separate test suite there. Wait...didn't we just do a patch so that PLs could be used? Do we have regression tests for that? LIke we have to triggers? Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org -
Re: [HACKERS] PL code and fmgr_addr
Jan Wieck <jwieck@debis.com> — 1998-02-06T10:15:58Z
> > On Thu, 5 Feb 1998, Jan Wieck wrote: > > > > > > > On Thu, 5 Feb 1998, Jan Wieck wrote: > > > > > > > > > > > > > Another problem I found with the PL code was that it took the fmgr() > > > > > macro, and made it call a function call to fmgr_addr, which just killed > > > > > performance. > > > > > > > > > > I made fmgr_addr() a macro too. > > > > > > > > > > -- > > > > > Bruce Momjian > > > > > maillist@candle.pha.pa.us > > > > > > > > > > > > > > > > > > Just to let you know - after fixing some other problems > > > > caused by the bpchar trouble my PLtcl tests went through > > > > again. Looks the macroization is O.K. > > > > > > Do we have regression tests for this? > > > > > > > > > > > > > No - since PLtcl isn't part of the distribution up to now. > > And I think that even if we include PLtcl into the dist we > > shouldn't include it into the regression tests because > > building PLtcl requires a Tcl installation (at least the > > libtcl??.so and tclConfig.sh). > > > > But it would be O.K. for me to include the PLtcl to the > > contrib directory and setup a separate test suite there. > > Wait...didn't we just do a patch so that PLs could be used? Do we > have regression tests for that? LIke we have to triggers? Up to now we don't have a PL that is independent. The patch only prepared the backend for a generic PL interface (CREATE PROCEDURAL LANGUAGE and the fmgr changes that a handler is called for functions of that language) and I tested all that with PLtcl, which for sake isn't in the dist right now. The current regression tests only enshure that the slightly modified fmgr doesn't break anything that worked before. And I think this should be the state until we have a real PL/pgSQL. I have some ideas for a PL/pgSQL. And I will create a regression test for it while implementing. > > Marc G. Fournier > Systems Administrator @ hub.org > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > > > -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #