On Thu, Jan 30, 2014 at 12:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> If I understand this test scenario properly, there are no duplicate
>> queries, so that each iteration creates a new hashtable entry (possibly
>> evicting an old one). And it's a single-threaded test, so that there
>> can be no benefit from reduced locking.
>
> After looking more closely, it's *not* single-threaded, but each pgbench
> thread is running through the same sequence of 10000 randomly generated
> SQL statements. So everything depends on how nearly those clients stay
> in step. I bet they'd stay pretty nearly in step, though --- any process
> lagging behind would find all the hashtable entries already created, and
> thus be able to catch up relative to the ones in the lead which are being
> slowed by having to write out their query texts. So it seems fairly
> likely that this scenario is greatly stressing the case where multiple
> processes redundantly create the same hashtable entry. In any case,
> while the same table entry does get touched once-per-client over a short
> interval, there's no long-term reuse of table entries. So I still say
> this isn't at all representative of real-world use of pg_stat_statements.
One could test it with each pgbench thread starting at a random point
in the same sequence and wrapping at the end.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company