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: | F Harvell <fharvell(at)fts(dot)net>, Dann Corbit <DCorbit(at)connx(dot)com>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: eWeek Poll: Which database is most critical to |
Date: | 2002-02-28 03:56:01 |
Message-ID: | 200202280356.g1S3u1921476@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> In general, Postgres' query plans *do* depend on the values of
> constants, and it's not always possible to produce an equally good plan
> that doesn't assume anything about constants. This is why I think it's
> a lousy idea for the system to try to automatically abstract a
> parameterized query plan from the actual queries it sees. On the other
> hand, an application programmer will have a very good idea of which
> parts of a repeated query are really constant and which are parameters.
> So what we really need is preparable parameterized queries, wherein the
> application tells us what to parameterize, rather than having to guess
> about it.
I think we could store the constants that went with the saved plan and
re-use the plan if the new constants were _similar_ to the old ones.
(Of course, figuring out _similar_ is the trick here.)
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Dominic J. Eidson | 2002-02-28 04:25:31 | Re: Arch (was RE: Refactoring of command.c ) |
Previous Message | Tom Lane | 2002-02-28 03:44:38 | Re: Point in time recovery: recreating relation files |