From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Peter Childs <Blue(dot)Dragon(at)blueyonder(dot)co(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] 7.4Beta |
Date: | 2003-08-15 22:17:33 |
Message-ID: | 200308152217.h7FMHX317638@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Is there a TODO here?
---------------------------------------------------------------------------
Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> > I'm thinking instead of a way to "cache" entire executors for this. Each
> > SPI plan used during a transaction would need it's own executor, and I
> > don't know offhand what type and how much resources an executor requires
> > (I think it's only some memory that get's initialized and the VFD's
> > opened).
>
> Hmm. This is probably more feasible now than it would have been a year
> ago, because I did some cleanup work to ensure that executor state is
> localized into a specific memory context. I'm not certain about the
> amount of overhead either, but it's surely worth a try.
>
> regards, tom lane
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Glen Eustace | 2003-08-15 22:21:58 | Dreamweaver |
Previous Message | Milton Yutaka Nishiyama Junior | 2003-08-15 21:19:13 | Problems installing DBD::Pg on Tru64 Unix !!!! |
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2003-08-15 22:41:15 | Re: New function: epoch_to_timestamp... |
Previous Message | Merlin Moncure | 2003-08-15 21:07:45 | Re: best way to retreive the next record in a multi column index |