From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Simon Riggs <simon(at)2ndquadrant(dot)com>, alvherre(at)commandprompt(dot)com, david(at)fetter(dot)org, pgsql-hackers(at)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us |
Subject: | Re: Page Checksums + Double Writes |
Date: | 2011-12-23 19:57:42 |
Message-ID: | CAMkU=1yDc_OK4Rs=YrK7cANQXSuYkaOezJ3LbiG_XVeNauE7TQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/23/11, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Dec 23, 2011 at 11:14 AM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Thoughts?
>
> Those are good thoughts.
>
> Here's another random idea, which might be completely nuts. Maybe we
> could consider some kind of summarization of CLOG data, based on the
> idea that most transactions commit.
I had a perhaps crazier idea. Aren't CLOG pages older than global xmin
effectively read only? Could backends that need these bypass locking
and shared memory altogether?
> An obvious problem is that, if the abort rate is significantly
> different from zero, and especially if the aborts are randomly mixed
> in with commits rather than clustered together in small portions of
> the XID space, the CLOG rollup data would become useless. On the
> other hand, if you're doing 10k tps, you only need to have a window of
> a tenth of a second or so where everything commits in order to start
> getting some benefit, which doesn't seem like a stretch.
Could we get some major OLTP users to post their CLOG for analysis? I
wouldn't think there would be much security/propietary issues with
CLOG data.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-12-23 20:06:56 | Re: Page Checksums + Double Writes |
Previous Message | Heikki Linnakangas | 2011-12-23 19:54:23 | Re: Moving more work outside WALInsertLock |