|From:||Florian Pflug <fgp(at)phlo(dot)org>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Jim Nasby <jim(at)nasby(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, alvherre(at)commandprompt(dot)com, david(at)fetter(dot)org, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us|
|Subject:||Re: Page Checksums + Double Writes|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Jan4, 2012, at 21:27 , Robert Haas wrote:
> I think the first thing we need to look at is increasing the number of
> CLOG buffers.
What became of the idea to treat the stable (i.e. earlier than the oldest
active xid) and the unstable (i.e. the rest) parts of the CLOG differently.
On 64-bit machines at least, we could simply mmap() the stable parts of the
CLOG into the backend address space, and access it without any locking at all.
I believe that we could also compress the stable part by 50% if we use one
instead of two bits per txid. AFAIK, we need two bits because we
a) Distinguish between transaction where were ABORTED and those which never
completed (due to i.e. a backend crash) and
b) Mark transaction as SUBCOMMITTED to achieve atomic commits.
Which both are strictly necessary for the stable parts of the clog. Note that
we could still keep the uncompressed CLOG around for debugging purposes - the
additional compressed version would require only 2^32/8 bytes = 512 MB in the
worst case, which people who're serious about performance can very probably
The fly in the ointment are 32-bit machines, of course - but then, those could
still fall back to the current way of doing things.
|Next Message||Manabu Ori||2012-01-05 12:40:56||Re: spinlocks on powerpc|
|Previous Message||Heikki Linnakangas||2012-01-05 10:58:09||Re: WIP: Join push-down for foreign tables|