Skip site navigation (1) Skip section navigation (2)

Re: eWeek Poll: Which database is most critical to

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: (view raw, whole thread or download thread mbox)
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                        |
  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

In response to

pgsql-hackers by date

Next:From: Dominic J. EidsonDate: 2002-02-28 04:25:31
Subject: Re: Arch (was RE: Refactoring of command.c )
Previous:From: Tom LaneDate: 2002-02-28 03:44:38
Subject: Re: Point in time recovery: recreating relation files

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group