Re: Add database to PGXACT / per database vacuuming - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Add database to PGXACT / per database vacuuming
Date
Msg-id 5220E133.3030109@vmware.com
Whole thread Raw
In response to Re: Add database to PGXACT / per database vacuuming  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On 30.08.2013 21:07, Heikki Linnakangas wrote:
> On 30.08.2013 19:01, Andres Freund wrote:
>> For the logical decoding patch I added support for pegging
>> RecentGlobalXmin (and GetOldestXmin) to a lower value. To avoid causing
>> undue bloat& cpu overhead (hot pruning is friggin expensive) I split
>> RecentGlobalXmin into RecentGlobalXmin and RecentGlobalDataXmin where
>> the latter is the the xmin horizon used for non-shared, non-catalog
>> tables. That removed almost all overhead I could measure.
>>
>> During that I was tinkering with the idea of reusing that split to
>> vacuum/prune user tables in a per db fashion. In a very quick and hacky
>> test that sped up the aggregate performance of concurrent pgbenches in
>> different databases by about 30%. So, somewhat worthwile ;).
>>
>> The problem with that is that GetSnapshotData, which computes
>> RecentGlobalXmin, only looks at the PGXACT structures and not PGPROC
>> which contains the database oid. This is a recently added optimization
>> which made GetSnapshotData() quite a bit faster& scalable which is
>> important given the frequency it's called at.
>
> Hmm, so you're creating a version of GetSnapshotData() that only takes
> into account backends in the same backend?

I mean, only takes account backends in the same database?

- Heikki



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Add database to PGXACT / per database vacuuming
Next
From: Andres Freund
Date:
Subject: Re: Add database to PGXACT / per database vacuuming