dependency between numbers keywords and parser speed
Hello,
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
pgbench when I increased a number of keywords.
I added a 30 reserved keywords and 30 unreserved keywords.
On my Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz wasn't a
significant difference between patched and unpatched server.
Tested read only queries. I am sure, so there will be any dependency,
but it probably needs more keywords, then I tested.
Regards
Pavel Stehule
Pavel Stehule <pavel.stehule@gmail.com> writes:
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
pgbench when I increased a number of keywords.
I don't see any particular reason to suppose that pgbench would be a
good framework for stressing parsing speed. The queries it issues
are of trivial length.
regards, tom lane
On 3/14/11 1:34 PM, Tom Lane wrote:
Pavel Stehule <pavel.stehule@gmail.com> writes:
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
pgbench when I increased a number of keywords.I don't see any particular reason to suppose that pgbench would be a
good framework for stressing parsing speed. The queries it issues
are of trivial length.
TPC-H might work well. Mark, is DBT3 still in usable condition?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Mon, Mar 14, 2011 at 4:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Stehule <pavel.stehule@gmail.com> writes:
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
pgbench when I increased a number of keywords.I don't see any particular reason to suppose that pgbench would be a
good framework for stressing parsing speed. The queries it issues
are of trivial length.
I found that it was actually a fairly measurable component of the
select-only test when running with shared_buffers cranked up to a
reasonable value. But it'd probably be a lot easier to measure on a
benchmark specifically targeted at the parser.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
2011/3/15 Robert Haas <robertmhaas@gmail.com>:
On Mon, Mar 14, 2011 at 4:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Stehule <pavel.stehule@gmail.com> writes:
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
pgbench when I increased a number of keywords.I don't see any particular reason to suppose that pgbench would be a
good framework for stressing parsing speed. The queries it issues
are of trivial length.I found that it was actually a fairly measurable component of the
select-only test when running with shared_buffers cranked up to a
reasonable value. But it'd probably be a lot easier to measure on a
benchmark specifically targeted at the parser.
When I tested it - all data was in memory, there was a minimal (near
zero IO) and I run read only test.
It doesn't mean, so parser is gratis, but my numbers doesn't show any
potential problem with 60 new keywords.
Pavel
Show quoted text
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, Mar 15, 2011 at 2:19 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2011/3/15 Robert Haas <robertmhaas@gmail.com>:
On Mon, Mar 14, 2011 at 4:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Stehule <pavel.stehule@gmail.com> writes:
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
pgbench when I increased a number of keywords.I don't see any particular reason to suppose that pgbench would be a
good framework for stressing parsing speed. The queries it issues
are of trivial length.I found that it was actually a fairly measurable component of the
select-only test when running with shared_buffers cranked up to a
reasonable value. But it'd probably be a lot easier to measure on a
benchmark specifically targeted at the parser.When I tested it - all data was in memory, there was a minimal (near
zero IO) and I run read only test.It doesn't mean, so parser is gratis, but my numbers doesn't show any
potential problem with 60 new keywords.
That's an interesting result, although it would be more interesting if
you posted the patch and benchmark methodology. It's important for us
not to overestimate the cost of adding keywords, and I don't object to
adding them where it adds meaningful clarity that is not otherwise
available or where it is necessary to comply with the SQL spec. But I
do think it is worth being disciplined about. We should think about
wording commands in a way that won't require new keywords; if there's
not a reasonable way to do it, then we add a keyword. Our preference
should be not to add keywords where that's reasonably possible.
It is particularly important for us to avoid keywords that are
partially or fully reserved. In that case, the issue is not parser
overhead but the fact that it breaks compatibility with previous
releases. pg_dump files can't be loaded, PL/pgsql procedures break,
and so on. I have been here and it isn't fun.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
2011/3/15 Robert Haas <robertmhaas@gmail.com>:
On Tue, Mar 15, 2011 at 2:19 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2011/3/15 Robert Haas <robertmhaas@gmail.com>:
On Mon, Mar 14, 2011 at 4:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Stehule <pavel.stehule@gmail.com> writes:
there was a discussion about impact of number of keyword for parser
speed. I did some synthetic tests and I didn't see any slowness on
pgbench when I increased a number of keywords.I don't see any particular reason to suppose that pgbench would be a
good framework for stressing parsing speed. The queries it issues
are of trivial length.I found that it was actually a fairly measurable component of the
select-only test when running with shared_buffers cranked up to a
reasonable value. But it'd probably be a lot easier to measure on a
benchmark specifically targeted at the parser.When I tested it - all data was in memory, there was a minimal (near
zero IO) and I run read only test.It doesn't mean, so parser is gratis, but my numbers doesn't show any
potential problem with 60 new keywords.That's an interesting result, although it would be more interesting if
you posted the patch and benchmark methodology. It's important for us
not to overestimate the cost of adding keywords, and I don't object to
adding them where it adds meaningful clarity that is not otherwise
available or where it is necessary to comply with the SQL spec. But I
do think it is worth being disciplined about. We should think about
wording commands in a way that won't require new keywords; if there's
not a reasonable way to do it, then we add a keyword. Our preference
should be not to add keywords where that's reasonably possible.It is particularly important for us to avoid keywords that are
partially or fully reserved. In that case, the issue is not parser
overhead but the fact that it breaks compatibility with previous
releases. pg_dump files can't be loaded, PL/pgsql procedures break,
and so on. I have been here and it isn't fun.
I agree and I understand well a problems with keywords. Just I would
to know a real limits of bison and I can say so 60 keywords are not a
problem.
Real test of parser's speed should be done on short and quick queries.
It can be unexpected so parser should be a bottle neck on long OLAP
queries.
Patch is added
Pavel
p.s. I am sure so this test depends on platform.
Show quoted text
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
keywords-test.difftext/x-patch; charset=US-ASCII; name=keywords-test.diffDownload
*** ./src/backend/parser/gram.y.orig 2011-03-15 17:01:59.000000000 +0100
--- ./src/backend/parser/gram.y 2011-03-14 20:54:02.000000000 +0100
***************
*** 568,573 ****
--- 568,585 ----
ZONE
+ AAAAAA AAABBB ABBBBB BAAAAA BAAAAB BAAABB
+ CAAAAA CAAAAC CAAACC DAAAAA DAAAAD DAAADD
+ IAAAAA IAAAAI IAAAII IAAIII IAIIII NAAAAA
+ NAAAAN NAAANN SAAAAA SAAAAS SAAASS SAASSS
+ SASSSS VAAAAA VAAAAV VAAAVV VAAVVV VABVVV
+
+ EAAAAA EAAAAE EAAAEE EAAEEE FAAAAA FAAAAF
+ FAAAFF FAAFFF OAAAAA OAAAAO OAAAOO OAAOOO
+ TAAAAA TAAAAT TAAATT TAATTT TATTTT UAAAAA
+ UAAAAU UAAAUU UAAUUU WAAAAA WAAAAW WAAAWW
+ WAAWWW WAWWWW XAAAAA XAAAAX XAAAXX XAAXXX
+
/*
* The grammar thinks these are keywords, but they are not in the kwlist.h
* list and so can never be entered directly. The filter in parser.c
***************
*** 12071,12076 ****
--- 12083,12119 ----
| YEAR_P
| YES_P
| ZONE
+
+ | EAAAAA
+ | EAAAAE
+ | EAAAEE
+ | EAAEEE
+ | FAAAAA
+ | FAAAAF
+ | FAAAFF
+ | FAAFFF
+ | OAAAAA
+ | OAAAAO
+ | OAAAOO
+ | OAAOOO
+ | TAAAAA
+ | TAAAAT
+ | TAAATT
+ | TAATTT
+ | TATTTT
+ | UAAAAA
+ | UAAAAU
+ | UAAAUU
+ | UAAUUU
+ | WAAAAA
+ | WAAAAW
+ | WAAAWW
+ | WAAWWW
+ | WAWWWW
+ | XAAAAA
+ | XAAAAX
+ | XAAAXX
+ | XAAXXX
;
/* Column identifier --- keywords that can be column, table, etc names.
***************
*** 12251,12256 ****
--- 12294,12330 ----
| WHERE
| WINDOW
| WITH
+
+ | AAAAAA
+ | AAABBB
+ | ABBBBB
+ | BAAAAA
+ | BAAAAB
+ | BAAABB
+ | CAAAAA
+ | CAAAAC
+ | CAAACC
+ | DAAAAA
+ | DAAAAD
+ | DAAADD
+ | IAAAAA
+ | IAAAAI
+ | IAAAII
+ | IAAIII
+ | IAIIII
+ | NAAAAA
+ | NAAAAN
+ | NAAANN
+ | SAAAAA
+ | SAAAAS
+ | SAAASS
+ | SAASSS
+ | SASSSS
+ | VAAAAA
+ | VAAAAV
+ | VAAAVV
+ | VAAVVV
+ | VABVVV
;
%%
*** ./src/include/parser/kwlist.h.orig 2011-03-15 17:00:33.207733416 +0100
--- ./src/include/parser/kwlist.h 2011-03-14 20:49:53.000000000 +0100
***************
*** 26,31 ****
--- 26,34 ----
*/
/* name, value, category */
+ PG_KEYWORD("aaaaaa", AAAAAA, RESERVED_KEYWORD)
+ PG_KEYWORD("aaabbb", AAABBB, RESERVED_KEYWORD)
+ PG_KEYWORD("abbbbb", ABBBBB, RESERVED_KEYWORD)
PG_KEYWORD("abort", ABORT_P, UNRESERVED_KEYWORD)
PG_KEYWORD("absolute", ABSOLUTE_P, UNRESERVED_KEYWORD)
PG_KEYWORD("access", ACCESS, UNRESERVED_KEYWORD)
***************
*** 51,56 ****
--- 54,62 ----
PG_KEYWORD("at", AT, UNRESERVED_KEYWORD)
PG_KEYWORD("attribute", ATTRIBUTE, UNRESERVED_KEYWORD)
PG_KEYWORD("authorization", AUTHORIZATION, TYPE_FUNC_NAME_KEYWORD)
+ PG_KEYWORD("baaaaa", BAAAAA, RESERVED_KEYWORD)
+ PG_KEYWORD("baaaab", BAAAAB, RESERVED_KEYWORD)
+ PG_KEYWORD("baaabb", BAAABB, RESERVED_KEYWORD)
PG_KEYWORD("backward", BACKWARD, UNRESERVED_KEYWORD)
PG_KEYWORD("before", BEFORE, UNRESERVED_KEYWORD)
PG_KEYWORD("begin", BEGIN_P, UNRESERVED_KEYWORD)
***************
*** 61,66 ****
--- 67,75 ----
PG_KEYWORD("boolean", BOOLEAN_P, COL_NAME_KEYWORD)
PG_KEYWORD("both", BOTH, RESERVED_KEYWORD)
PG_KEYWORD("by", BY, UNRESERVED_KEYWORD)
+ PG_KEYWORD("caaaaa", CAAAAA, RESERVED_KEYWORD)
+ PG_KEYWORD("caaaac", CAAAAC, RESERVED_KEYWORD)
+ PG_KEYWORD("caaacc", CAAACC, RESERVED_KEYWORD)
PG_KEYWORD("cache", CACHE, UNRESERVED_KEYWORD)
PG_KEYWORD("called", CALLED, UNRESERVED_KEYWORD)
PG_KEYWORD("cascade", CASCADE, UNRESERVED_KEYWORD)
***************
*** 111,116 ****
--- 120,128 ----
PG_KEYWORD("current_user", CURRENT_USER, RESERVED_KEYWORD)
PG_KEYWORD("cursor", CURSOR, UNRESERVED_KEYWORD)
PG_KEYWORD("cycle", CYCLE, UNRESERVED_KEYWORD)
+ PG_KEYWORD("daaaaa", DAAAAA, RESERVED_KEYWORD)
+ PG_KEYWORD("daaaad", DAAAAD, RESERVED_KEYWORD)
+ PG_KEYWORD("daaadd", DAAADD, RESERVED_KEYWORD)
PG_KEYWORD("data", DATA_P, UNRESERVED_KEYWORD)
PG_KEYWORD("database", DATABASE, UNRESERVED_KEYWORD)
PG_KEYWORD("day", DAY_P, UNRESERVED_KEYWORD)
***************
*** 136,141 ****
--- 148,157 ----
PG_KEYWORD("domain", DOMAIN_P, UNRESERVED_KEYWORD)
PG_KEYWORD("double", DOUBLE_P, UNRESERVED_KEYWORD)
PG_KEYWORD("drop", DROP, UNRESERVED_KEYWORD)
+ PG_KEYWORD("eaaaaa", EAAAAA, UNRESERVED_KEYWORD)
+ PG_KEYWORD("eaaaae", EAAAAE, UNRESERVED_KEYWORD)
+ PG_KEYWORD("eaaaee", EAAAEE, UNRESERVED_KEYWORD)
+ PG_KEYWORD("eaaeee", EAAEEE, UNRESERVED_KEYWORD)
PG_KEYWORD("each", EACH, UNRESERVED_KEYWORD)
PG_KEYWORD("else", ELSE, RESERVED_KEYWORD)
PG_KEYWORD("enable", ENABLE_P, UNRESERVED_KEYWORD)
***************
*** 154,159 ****
--- 170,179 ----
PG_KEYWORD("extension", EXTENSION, UNRESERVED_KEYWORD)
PG_KEYWORD("external", EXTERNAL, UNRESERVED_KEYWORD)
PG_KEYWORD("extract", EXTRACT, COL_NAME_KEYWORD)
+ PG_KEYWORD("faaaaa", FAAAAA, UNRESERVED_KEYWORD)
+ PG_KEYWORD("faaaaf", FAAAAF, UNRESERVED_KEYWORD)
+ PG_KEYWORD("faaaff", FAAAFF, UNRESERVED_KEYWORD)
+ PG_KEYWORD("faafff", FAAFFF, UNRESERVED_KEYWORD)
PG_KEYWORD("false", FALSE_P, RESERVED_KEYWORD)
PG_KEYWORD("family", FAMILY, UNRESERVED_KEYWORD)
PG_KEYWORD("fetch", FETCH, RESERVED_KEYWORD)
***************
*** 179,184 ****
--- 199,209 ----
PG_KEYWORD("header", HEADER_P, UNRESERVED_KEYWORD)
PG_KEYWORD("hold", HOLD, UNRESERVED_KEYWORD)
PG_KEYWORD("hour", HOUR_P, UNRESERVED_KEYWORD)
+ PG_KEYWORD("iaaaaa", IAAAAA, RESERVED_KEYWORD)
+ PG_KEYWORD("iaaaai", IAAAAI, RESERVED_KEYWORD)
+ PG_KEYWORD("iaaaii", IAAAII, RESERVED_KEYWORD)
+ PG_KEYWORD("iaaiii", IAAIII, RESERVED_KEYWORD)
+ PG_KEYWORD("iaiiii", IAIIII, RESERVED_KEYWORD)
PG_KEYWORD("identity", IDENTITY_P, UNRESERVED_KEYWORD)
PG_KEYWORD("if", IF_P, UNRESERVED_KEYWORD)
PG_KEYWORD("ilike", ILIKE, TYPE_FUNC_NAME_KEYWORD)
***************
*** 239,244 ****
--- 264,272 ----
PG_KEYWORD("mode", MODE, UNRESERVED_KEYWORD)
PG_KEYWORD("month", MONTH_P, UNRESERVED_KEYWORD)
PG_KEYWORD("move", MOVE, UNRESERVED_KEYWORD)
+ PG_KEYWORD("naaaaa", NAAAAA, RESERVED_KEYWORD)
+ PG_KEYWORD("naaaan", NAAAAN, RESERVED_KEYWORD)
+ PG_KEYWORD("naaann", NAAANN, RESERVED_KEYWORD)
PG_KEYWORD("name", NAME_P, UNRESERVED_KEYWORD)
PG_KEYWORD("names", NAMES, UNRESERVED_KEYWORD)
PG_KEYWORD("national", NATIONAL, COL_NAME_KEYWORD)
***************
*** 263,268 ****
--- 291,300 ----
PG_KEYWORD("nullif", NULLIF, COL_NAME_KEYWORD)
PG_KEYWORD("nulls", NULLS_P, UNRESERVED_KEYWORD)
PG_KEYWORD("numeric", NUMERIC, COL_NAME_KEYWORD)
+ PG_KEYWORD("oaaaaa", OAAAAA, UNRESERVED_KEYWORD)
+ PG_KEYWORD("oaaaao", OAAAAO, UNRESERVED_KEYWORD)
+ PG_KEYWORD("oaaaoo", OAAAOO, UNRESERVED_KEYWORD)
+ PG_KEYWORD("oaaooo", OAAOOO, UNRESERVED_KEYWORD)
PG_KEYWORD("object", OBJECT_P, UNRESERVED_KEYWORD)
PG_KEYWORD("of", OF, UNRESERVED_KEYWORD)
PG_KEYWORD("off", OFF, UNRESERVED_KEYWORD)
***************
*** 329,334 ****
--- 361,371 ----
PG_KEYWORD("row", ROW, COL_NAME_KEYWORD)
PG_KEYWORD("rows", ROWS, UNRESERVED_KEYWORD)
PG_KEYWORD("rule", RULE, UNRESERVED_KEYWORD)
+ PG_KEYWORD("saaaaa", SAAAAA, RESERVED_KEYWORD)
+ PG_KEYWORD("saaaas", SAAAAS, RESERVED_KEYWORD)
+ PG_KEYWORD("saaass", SAAASS, RESERVED_KEYWORD)
+ PG_KEYWORD("saasss", SAASSS, RESERVED_KEYWORD)
+ PG_KEYWORD("sassss", SASSSS, RESERVED_KEYWORD)
PG_KEYWORD("savepoint", SAVEPOINT, UNRESERVED_KEYWORD)
PG_KEYWORD("schema", SCHEMA, UNRESERVED_KEYWORD)
PG_KEYWORD("scroll", SCROLL, UNRESERVED_KEYWORD)
***************
*** 365,370 ****
--- 402,412 ----
PG_KEYWORD("symmetric", SYMMETRIC, RESERVED_KEYWORD)
PG_KEYWORD("sysid", SYSID, UNRESERVED_KEYWORD)
PG_KEYWORD("system", SYSTEM_P, UNRESERVED_KEYWORD)
+ PG_KEYWORD("taaaaa", TAAAAA, UNRESERVED_KEYWORD)
+ PG_KEYWORD("taaaat", TAAAAT, UNRESERVED_KEYWORD)
+ PG_KEYWORD("taaatt", TAAATT, UNRESERVED_KEYWORD)
+ PG_KEYWORD("taattt", TAATTT, UNRESERVED_KEYWORD)
+ PG_KEYWORD("tatttt", TATTTT, UNRESERVED_KEYWORD)
PG_KEYWORD("table", TABLE, RESERVED_KEYWORD)
PG_KEYWORD("tables", TABLES, UNRESERVED_KEYWORD)
PG_KEYWORD("tablespace", TABLESPACE, UNRESERVED_KEYWORD)
***************
*** 385,390 ****
--- 427,436 ----
PG_KEYWORD("truncate", TRUNCATE, UNRESERVED_KEYWORD)
PG_KEYWORD("trusted", TRUSTED, UNRESERVED_KEYWORD)
PG_KEYWORD("type", TYPE_P, UNRESERVED_KEYWORD)
+ PG_KEYWORD("uaaaaa", UAAAAA, UNRESERVED_KEYWORD)
+ PG_KEYWORD("uaaaau", UAAAAU, UNRESERVED_KEYWORD)
+ PG_KEYWORD("uaaauu", UAAAUU, UNRESERVED_KEYWORD)
+ PG_KEYWORD("uaauuu", UAAUUU, UNRESERVED_KEYWORD)
PG_KEYWORD("unbounded", UNBOUNDED, UNRESERVED_KEYWORD)
PG_KEYWORD("uncommitted", UNCOMMITTED, UNRESERVED_KEYWORD)
PG_KEYWORD("unencrypted", UNENCRYPTED, UNRESERVED_KEYWORD)
***************
*** 397,402 ****
--- 443,453 ----
PG_KEYWORD("update", UPDATE, UNRESERVED_KEYWORD)
PG_KEYWORD("user", USER, RESERVED_KEYWORD)
PG_KEYWORD("using", USING, RESERVED_KEYWORD)
+ PG_KEYWORD("vaaaaa", VAAAAA, RESERVED_KEYWORD)
+ PG_KEYWORD("vaaaav", VAAAAV, RESERVED_KEYWORD)
+ PG_KEYWORD("vaaavv", VAAAVV, RESERVED_KEYWORD)
+ PG_KEYWORD("vaavvv", VAAVVV, RESERVED_KEYWORD)
+ PG_KEYWORD("vabvvv", VABVVV, RESERVED_KEYWORD)
PG_KEYWORD("vacuum", VACUUM, UNRESERVED_KEYWORD)
PG_KEYWORD("valid", VALID, UNRESERVED_KEYWORD)
PG_KEYWORD("validate", VALIDATE, UNRESERVED_KEYWORD)
***************
*** 410,415 ****
--- 461,471 ----
PG_KEYWORD("version", VERSION_P, UNRESERVED_KEYWORD)
PG_KEYWORD("view", VIEW, UNRESERVED_KEYWORD)
PG_KEYWORD("volatile", VOLATILE, UNRESERVED_KEYWORD)
+ PG_KEYWORD("waaaaa", WAAAAA, UNRESERVED_KEYWORD)
+ PG_KEYWORD("waaaaw", WAAAAW, UNRESERVED_KEYWORD)
+ PG_KEYWORD("waaaww", WAAAWW, UNRESERVED_KEYWORD)
+ PG_KEYWORD("waawww", WAAWWW, UNRESERVED_KEYWORD)
+ PG_KEYWORD("wawwww", WAWWWW, UNRESERVED_KEYWORD)
PG_KEYWORD("when", WHEN, RESERVED_KEYWORD)
PG_KEYWORD("where", WHERE, RESERVED_KEYWORD)
PG_KEYWORD("whitespace", WHITESPACE_P, UNRESERVED_KEYWORD)
***************
*** 419,424 ****
--- 475,484 ----
PG_KEYWORD("work", WORK, UNRESERVED_KEYWORD)
PG_KEYWORD("wrapper", WRAPPER, UNRESERVED_KEYWORD)
PG_KEYWORD("write", WRITE, UNRESERVED_KEYWORD)
+ PG_KEYWORD("xaaaaa", XAAAAA, UNRESERVED_KEYWORD)
+ PG_KEYWORD("xaaaax", XAAAAX, UNRESERVED_KEYWORD)
+ PG_KEYWORD("xaaaxx", XAAAXX, UNRESERVED_KEYWORD)
+ PG_KEYWORD("xaaxxx", XAAXXX, UNRESERVED_KEYWORD)
PG_KEYWORD("xml", XML_P, UNRESERVED_KEYWORD)
PG_KEYWORD("xmlattributes", XMLATTRIBUTES, COL_NAME_KEYWORD)
PG_KEYWORD("xmlconcat", XMLCONCAT, COL_NAME_KEYWORD)
On Tue, Mar 15, 2011 at 05:09:47PM +0100, Pavel Stehule wrote:
Real test of parser's speed should be done on short and quick queries.
It can be unexpected so parser should be a bottle neck on long OLAP
queries.
Surely parsing overhead could be measured by simply PREPAREing every
query, rather than executing them.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
Patriotism is when love of your own people comes first; nationalism,
when hate for people other than your own comes first.
- Charles de Gaulle