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

Bruce Momjian wrote:

> > (A AND B) OR (C AND D) ==> (A AND B) UNION (C AND D)
> >
> > The rules to qualify are fairly strict. Must be have ANDs; rectangular in
> > shape; all (VAR op CONST) type nodes; minimum of 10 nodes; etc. I was
> > targeting the keysets queries generated by ODBC tools.
> >
> > As for the current direction this thread is going, (factoring) I have one
> > word of caution. PREPARE. If you take this route, you will never be able
> > to implement a workable PREPARE statement. I believe that in order for
> > PostgrerSQL ever become a industrial strength client/server it must implement
> > a PREPARE statement with parameters.
>
> 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.