On Wed, Jul 27, 2011 at 1:58 PM, Noah Misch <noah@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