Re: Improved scanner performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improved scanner performance
Date: 2002-04-21 02:05:45
Message-ID: 28753.1019354745@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

BTW, here is what I get on an HP box for the same test you described
(a dozen trivial SELECTs using string literals between 5MB and 10MB
long), using latest sources:

% cumulative self self total
time seconds seconds calls ms/call ms/call name
47.51 8.19 8.19 chunks
26.16 12.70 4.51 129 34.96 35.97 base_yylex
12.30 14.82 2.12 1521 1.39 1.39 strlen
6.79 15.99 1.17 13 90.00 90.00 pq_getstring
4.18 16.71 0.72 chunk2
2.55 17.15 0.44 _recv_sys
0.29 17.20 0.05 _mcount

"chunks" is the inner loop of memcpy() --- evidently all the time is
being spent just copying those big literals around.

We could probably avoid some of that copying if we had a cleaner
approach to parsetree handling, ie, no scribbling on one's input.
Then operations like eval_const_expressions wouldn't feel compelled
to copy parsetree nodes that they weren't modifying. But I think
we've gotten all the low-hanging fruit for now.

At least on the backend side. Did you notice that psql was chewing
up three times more CPU than the backend in this test??

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2002-04-21 02:07:18 Foreign keys and indexes.
Previous Message Tom Lane 2002-04-21 00:35:03 Re: syslog support by default