From: | "Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com> |
---|---|
To: | bruce(at)momjian(dot)us |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org, neilc(at)samurai(dot)com |
Subject: | Re: [HACKERS] plpgsql, return can contains any expression |
Date: | 2007-02-09 05:18:51 |
Message-ID: | BAY114-F38C6E97F724F0686ACC43DF99C0@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
>
>OK, where are we on this patch?
without changes. This task have to do anybody who better know PostgreSQL
cache system than me.
Regards
Pavel
>
>---------------------------------------------------------------------------
>
>Pavel Stehule wrote:
> >
> >
> > >
> > >"Pavel Stehule" <pavel(dot)stehule(at)hotmail(dot)com> writes:
> > > >> This patch doesn't seem to cope with cases where the supplied tuple
>has
> > > >> the wrong number of columns, and it doesn't look like it's being
> > >careful
> > > >> about dropped columns either. Also, that's a mighty
>bizarre-looking
> > > >> choice of cache memory context in coerce_to_tuple ... but then
>again,
> > > >> why are you bothering with a cache at all for temporary arrays?
> > >
> > > > I am sorry, Tom. But I don't understand. I can check number of
>columns,
> > > > ofcourse and I'll do it. What cache for temporary arrays do you
>mean?
> > >
> > >I thought that making coerce_to_tuple depend on estate->err_func was
> > >pretty bizarre, and that there was no need for any "cache" at all for
> > >arrays that need only live as long as the function runs. All you are
> > >saving here is a palloc/pfree cycle, which is not worth the
>obscurantism
> > >and risk of bugs (are you sure natts can never change?).
> >
> > No, cache there is ugly. But I don't have idea about more efective
> > implementation of it :-(. First version of this patch was more clean.
>and
> > little bit slow. This cache save 10%.
> >
> > >
> > >BTW, if you want this patch to make it into 8.2, it needs to be fixed
> > >and resubmitted *very* soon.
> >
> > I understand, but I am not able work on it in next four days. And I need
> > help with it from Neil. It will be for 8.3.
> >
> > Thank you
> > Pavel
> >
> > _________________________________________________________________
> > Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci.
> > http://messenger.msn.cz/
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: don't forget to increase your free space map settings
>
>--
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
>---------------------------(end of broadcast)---------------------------
>TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate
_________________________________________________________________
Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2007-02-09 05:22:03 | Re: better support of out parameters in plperl |
Previous Message | Koichi Suzuki | 2007-02-09 05:14:42 | Re: Archive log compression keeping physical log available in the crash recovery |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2007-02-09 05:22:03 | Re: better support of out parameters in plperl |
Previous Message | Chris Marcellino | 2007-02-09 05:05:04 | Feature: POSIX Shared memory support, round 2 |