On Wed, Jul 27, 2011 at 1:58 PM, Noah Misch <n...@2ndquadrant.com> wrote: >> > I think a benchmark is in order, something like 900 idle connections and 80 >> > connections running small transactions that create a few temporary tables. >> > If >> > that shows no statistically significant regression, then we're probably >> > fine >> > here. I'm not sure what result to expect, honestly. >> >> That's setting the bar pretty high. I don't mind doing the >> experiment, but I'm not sure that's the case we should be optimizing >> for. > > Granted. How about 32 clients running the temporary table transaction, no > idle > connections? Given the meager benefit of this patch compared to your previous > version, it would be hard to justify a notable performance drop in return.
The reason the benefit is smaller is, I believe, because the previous numbers were generated with the lazy vxid locks patch applied, and these were generated against master. With the lock manager as a bottleneck, the sinval stuff doesn't get hit quite as hard, so the benefit is less. I can regenerate the numbers with the lazy vxid patch applied; I suspect they'll be similar to what we saw before. I'll also test out creating and dropping some tables. -- 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
