| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | Douglas Doole <dougdoole(at)gmail(dot)com>,Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>,Robert Haas <robertmhaas(at)gmail(dot)com>,Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>,PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Cached plans and statement generalization |
| Date: | 2017-05-11 18:32:26 |
| Message-ID: | D04FA46E-AD8C-418C-8348-C6DC5C49F18D@anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On May 11, 2017 11:31:02 AM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Bruce Momjian <bruce(at)momjian(dot)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.
And that there's a lot of unpredictable branches, leading to a lot if pipeline stalls.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2017-05-11 19:32:36 | Re: WITH clause in CREATE STATISTICS |
| Previous Message | Tom Lane | 2017-05-11 18:31:02 | Re: Cached plans and statement generalization |