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 02:41:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
> > I see that adding nodes it going to mess up prepare, but we already add
> > extra nodes as part of part of "col in (1, 2, 3)."
> It's not extra nodes I am worried about.  It is factored out nodes.
> > I think the PARAM's we already use will be duplicated/removed and still
> > retain their values for substitution.  They just may be in a different
> > order.
> I realize I may be stretching the point, since I brought it up I will complete my
> thoughts. Now, you may understand this, but just to be sure.  Here is a typical
> client/server scenario:
>     - prepare statement S
>     - retrieve result description of S
>     - retrieve number of parameters of S
>     - retrieve parameter descriptions of S
>     - put data into parameters of S
>     - execute S
>     - retrieve result
>     [REPEAT]
>     - put different data into parameters of S
>     - execute S
>     - retrieve result
>     [END REPEAT]
>     - free statement S
> 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.
> The other major benefits are:
> 1. Gaining access to the statement result description w/o having to actually
> execute the statement.  Client/server tools live off this stuff.
> 2. Smaller statement size.  The parameters in the WHERE clause can be sent to that
> backend in separate chunks.
> Back to the subject at hand.
> My point is that the factoring approach may be a bit short sighted in the long term
> evolution of PostgreSQL.

Yikes.  I see what you mean.  The factoring of one query with certain
constants will be different than another query.  That will certainly be
a problem.

I still haven't had time to look over the cnfify code, to see if calling
qual_cleanup earlier in the code will help reduce the palloc failures. 
If it is easy to do, I will implement it, and we can remove it or change
it once we start looking at prepared queries.

  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: Bruce MomjianDate: 1998-10-07 02:50:38
Subject: Re: [HACKERS] pg_dump and more
Previous:From: Bruce MomjianDate: 1998-10-06 22:08:59
Subject: Re: [HACKERS] pg_dump and more

pgsql-general by date

Next:From: Bruce MomjianDate: 1998-10-07 02:43:33
Subject: Re: [GENERAL] status on IPv6 implementation...
Previous:From: anilDate: 1998-10-07 02:40:08
Subject: SQL Help

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