Add database to PGXACT / per database vacuuming

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Add database to PGXACT / per database vacuuming
Date: 2013-08-30 16:01:11
Message-ID: 20130830160111.GA25190@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

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.

What about moving/copying the database oid from PGPROC to PGXACT?
Currently a single PGXACT is 12 bytes which means we a) have several
entries in a single cacheline b) have ugly sharing because we will have
PGXACTs split over more than one cacheline.

Comments?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-08-30 17:36:50 Re: [v9.4] row level security
Previous Message Andres Freund 2013-08-30 15:45:39 Re: dynamic shared memory