On Thu, Jan 30, 2014 at 12:23 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
