pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: Douglas Doole <dougdoole@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Cc: Andres Freund <andres@anarazel.de>
Subject: Re: Cached plans and statement generalization
Date: Thu, 11 May 2017 22:48:26 +0300
Message-ID: <5914C00A.9030908@postgrespro.ru> (raw)
In-Reply-To: <22696.1494527462@sss.pgh.pa.us>
References: <bda56ce2-64fa-8236-b3a9-71db71b41c6b@postgrespro.ru>
	<7741e358-ff0e-af5d-9899-306b20a1a6e1@postgrespro.ru>
	<CAFj8pRDRfva3b4+xL7s1jUEOCKVZ4Q14NnajVjwpoR80XJdaVA@mail.gmail.com>
	<304dfa09-6135-cbcf-d6e5-1ea6c36e6eec@postgrespro.ru>
	<CA+TgmoZAHc4wqL3HvVmTd87s=bobp_8_7R9H=B_kH6q4GcA=Yg@mail.gmail.com>
	<4bd78cd4-1e64-5294-2eb8-3d061b20288f@postgrespro.ru>
	<CA+TgmoaCAoSrU9TL8t5J3YP9xp1P-0f5vySy74Rd5kPKLNuqfQ@mail.gmail.com>
	<8eed9c23-19ba-5404-7a9e-0584b836b3f3@postgrespro.ru>
	<20170511151233.GE17200@momjian.us>
	<CADE5jYJ3g-c6R45cD7KUmfpiOPRzhmf9t820d4cQzmnsnaU6eA@mail.gmail.com>
	<20170511181505.GA25894@momjian.us>
	<22696.1494527462@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

On 05/11/2017 09:31 PM, Tom Lane wrote:
> Bruce Momjian <bruce@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.


-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers



view thread (107+ messages)  latest in thread

Message-ID: <5914C00A.9030908@postgrespro.ru>
Permalink:  ../5914C00A.9030908@postgrespro.ru/
Also on:    postgresql.org/message-id/5914C00A.9030908@postgrespro.ru

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: k.knizhnik@postgrespro.ru, tgl@sss.pgh.pa.us, bruce@momjian.us, dougdoole@gmail.com, robertmhaas@gmail.com, pavel.stehule@gmail.com, andres@anarazel.de
  Subject: Re: Cached plans and statement generalization
  In-Reply-To: <5914C00A.9030908@postgrespro.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox