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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers