On Fri, Jun 17, 2011 at 7:24 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jun 17, 2011 at 1:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah, this seems like a possibly workable direction to explore. I like
>> this better than what Simon is proposing, because it would fix the
>> generic issue for all types of catalog SnapshotNow scans.
>
> It would also avoid adding more lock manager traffic which - as
> recently discussed on the relevant threads - turns out to be a
> significant performance bottleneck for us right now on some workloads.
>> I am not, however, particularly pleased with the idea of trying to make
>> this work in 9.1. I still think that we should back off the attempt
>> to reduce lock strength in 9.1, and take it up for 9.2. We need to be
>> stabilizing 9.1 for release, not introducing new untested mechanisms in
>> it.
>
> I like this feature a lot, but it's hard to imagine that any of the
> fixes anyone has so far suggested can be implemented without
> collateral damage. Nor is there any certainty that this is the last
> bug.
Not so. The extra locking would only occur on the first lock
acquisition after DDL operations occur. If that was common then your
other performance patch would not be an effective optimisation. There
is no additional locking from what I've proposed in the common code
path - that's why we have a relcache.
Any effects from the additional locking will only be felt by people
issuing a stream of DDL statements against a table. Even assuming
there are some effects of real note.
So there is no "collateral damage" and additional locking is a viable
solution for 9.1.
It's possible that we may have a better solution in 9.2+ but then
we've said that before and have it never happen, many times.
Having spent a few hours mulling through this, I think there is a
reasonable solution for 9.1 and I continue to work on it.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services