On 2017-05-11 22:48:26 +0300, Konstantin Knizhnik wrote: > On 05/11/2017 09:31 PM, Tom Lane wrote: > > Bruce Momjian <br...@momjian.us> writes: > > > Good point. I think we need to do some measurements to see if the > > > parser-only stage is actually significant. I have a hunch that > > > commercial databases have much heavier parsers than we do. > > FWIW, gram.y does show up as significant in many of the profiles I take. > > I speculate that this is not so much that it eats many CPU cycles, as that > > the constant tables are so large as to incur lots of cache misses. scan.l > > is not quite as big a deal for some reason, even though it's also large. > > > > regards, tom lane > Yes, my results shows that pg_parse_query adds not so much overhead: > 206k TPS for my first variant with string literal substitution and modified > query text used as hash key vs. > 181k. TPS for version with patching raw parse tree constructed by > pg_parse_query.
Those numbers and your statement seem to contradict each other? - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
