Re: VALUES clause memory optimization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "Hackers (PostgreSQL)" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: VALUES clause memory optimization
Date: 2006-08-04 04:56:26
Message-ID: 2050.1154667386@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers pgsql-patches

Joe Conway <mail(at)joeconway(dot)com> writes:
> What about for the specific case of an InsertStmt? It seems that we
> could at least get away with freeing the raw-expression list in that case.

Not sure ... what about rules, BETWEEN, yadda yadda?

> In terms of freeing an entire arbitrary node, could we create a
> backend/nodes/freefuncs.c file that does a recursive freeObject()
> similar to the way copyObject() does in backend/nodes/copyfuncs.c?

We got rid of freefuncs.c years ago, for good and sufficient reasons
that have not gone away. The problem is exactly that you don't know
whether any shortcuts were taken in constructing the node tree:
multiple links, pointers to constants, pointers to stuff that wasn't
supposed to be freed are all severe hazards.

>> My advice is to get that low-hanging fruit
>> in transformInsertRow and leave the other ideas for 8.3.

> OK. This should be safe also, correct?

Yes, but what's your point? The case that seems worth trying to
optimize is "INSERT INTO foo VALUES ... real long list ...". Certainly
the MySQL crowd is not going to be stressing transformValuesClause,
because they don't know it exists.

$ mysql test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 12 to server version: 5.0.22

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> values (1),(2);
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'values (1),(2)' at line 1
mysql> select * from (values (1),(2)) as x(y);
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'values (1),(2)) as x(y)' at line 1
mysql> select * from foo where x in (values (1),(2));
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1),(2))' at line 1
mysql>

mysql shortcomings aside, I don't really see the use-case for enormously
long VALUES lists anywhere except the bulk-data-load scenario, ie,
exactly INSERT ... VALUES. So I don't feel a need to be real tense
in transformValuesClause.

regards, tom lane

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Peter Eisentraut 2006-08-04 07:02:09 Re: Values list-of-targetlists patch for comments (was Re: [PATCHES]
Previous Message Pavel Stehule 2006-08-04 04:43:08 Re: Values list-of-targetlists patch for comments (was Re: [PATCHES]

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2006-08-04 05:22:01 Re: 8.2 features status
Previous Message Bruce Momjian 2006-08-04 04:47:05 Re: 8.2 features status

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2006-08-04 07:02:09 Re: Values list-of-targetlists patch for comments (was Re: [PATCHES]
Previous Message Pavel Stehule 2006-08-04 04:43:08 Re: Values list-of-targetlists patch for comments (was Re: [PATCHES]