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

Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: daveh(at)insightdist(dot)com (David Hartwig)
Cc: taral(at)mail(dot)utexas(dot)edu, jwieck(at)debis(dot)com, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)
Date: 1998-10-07 17:56:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
> The problem is that you cannot depend upon factoring to reduce these complex
> statements.   We need to retain a place holder (pointer) for each passed
> parameter.   Otherwise we need to re-(parse and plan) the statement before each
> execution; thus, loosing one of the major benefits of PREPARE.

I think we already have such a problem.  When using optimization
statistics, the optimizer checks the value of the constant to determine
how many rows will be returned by a "x > 10" by looking at the min/max
values for the column.  Prepared queries where this value will change
would make that a problem.

  Bruce Momjian                        |
  maillist(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: David HartwigDate: 1998-10-07 20:34:15
Subject: Re: [HACKERS] RE: [GENERAL] Long update query ? (also Re: [GENERAL] CNF vs. DNF)
Previous:From: Bruce MomjianDate: 1998-10-07 17:14:07
Subject: Re: [HACKERS] Portability Issue in src/backend/port/snprintf.c (I think)

pgsql-general by date

Next:From: Anand SureliaDate: 1998-10-07 17:58:34
Subject: Row Nums
Previous:From: Jackson, DeJuanDate: 1998-10-07 16:34:40
Subject: RE: [GENERAL] SQL Help

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