Thread: PL code and fmgr_addr
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
>
> 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) #
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?
>
> 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) #
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
>
> 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) #