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

> > 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                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026