Re: Not HOT enough
Re: Not HOT enough
От:
Simon Riggs <simon@2ndQuadrant.com>
Дата:
On Tue, Nov 22, 2011 at 11:40 PM, Simon Riggs wrote: >> I think this is unsafe for shared catalogs. > > I think so too. Thats why it uses IsMVCCSnapshot() to confirm when it > is safe to do so. > Ah, you mean access to shared catalogs using MVCC snapshots. Fixed. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Not HOT enough
От:
Simon Riggs <simon@2ndQuadrant.com>
Дата:
Some time ago, I changed GetOldestXmin() to ignore procs in other databases resulting in a potentially later xmin. GetSnapshotData() was not touched when that happened, even though the comments say "...This is the same computation done by GetOldestXmin(true, true)." The transam/README file says it stronger "GetSnapshotData also performs an oldest-xmin calculation (which had better match GetOldestXmin's)". Doh. As a result, VACUUM ignores procs in other databases, whereas HOT does not. That means we aren't cleaning up as much as we could do when running multiple databases. If its OK for VACUUM, then it must be OK for HOT cleanup also. Attached patch ignores procs in other databases during GetSnapshotData() when IsMVCCSnapshot(), using similar coding to GetOldestXmin(). Any doubters? I suggest this is backpatched a few releases. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: Not HOT enough
От:
Simon Riggs <simon@2ndQuadrant.com>
Дата:
On Wed, Nov 23, 2011 at 6:15 PM, Tom Lane wrote: >> The real question is do we favour HOT cleanup on those small 8 tables, >> or do we favour HOT cleanup of every other table? > > No, the real question is why not think a little harder and see if we can > come up with a solution that doesn't involve making some cases worse to > make others better. Slightly modified patch attached. When we access a shared relation and the page is prunable we re-derive the cutoff value using GetOldestXmin. That code path is rarely taken. In particular, pg_shdepend is only accessed during object creation/alter/drop, so this isn't a path we can't spare a small amount little extra on, just like the trade-off we've taken to make locking faster for DML while making DDL a little slower. If this is still unacceptable, then I'll have to look at reducing impact on pg_shdepend from temp tables - which is still a plan. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
