Re: more anti-postgresql FUD

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, andrew(at)supernews(dot)com, pgsql-general(at)postgresql(dot)org
Subject: Re: more anti-postgresql FUD
Date: 2006-10-13 18:45:45
Message-ID: 1160765146.31966.283.camel@dogma.v10.wvs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Fri, 2006-10-13 at 13:07 -0500, Jim C. Nasby wrote:
> On Fri, Oct 13, 2006 at 01:52:10PM -0400, Merlin Moncure wrote:
> > On 10/13/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> > >> Is that really true? In theory block n+1 could be half a revolution
> > >> after block n, allowing you to commit two transactions per revolution.
> > >
> > >Not relevant, unless the prior transaction happened to end exactly at a
> >
> > does full page writes setting affect this?
>
> If anything it makes it more true, but full pages are only written the
> first time a page is dirtied after a checkpoint, so in a
> high-transaction system I suspect they don't have a lot of impact.
>
> It would be nice to have stats on how many transactions have to write a
> full page, as well as how many have been written, though...

Maybe rather than the number of transactions that are forced to write
full pages, would it be useful to know the fraction of the WAL traffic
used for full page writes? Otherwise, a transaction that dirtied one
data page would be counted the same as a transaction that dirtied 100
data pages.

I guess it gets tricky though, because you really need to know the
difference between what the volume of WAL traffic is and what it would
be if full_page_writes was disabled.

That brings up a question. Does a full page write happen in addition to
a record of the changes to that page, or instead of a record of the
changes to that page? If the answer is "in addition" the calculation
would just be a count of the pages dirtied between checkpoints. Or am I
way off base?

But yes, statistics in that area would be useful to know whether you
need to crank up the checkpoint_timeout. Ideas?

Regards,
Jeff Davis

In response to

Browse pgsql-general by date

  From Date Subject
Next Message J S B 2006-10-13 18:57:37 Re: Backup DB not getting connected
Previous Message Scott Marlowe 2006-10-13 18:42:39 Re: A query planner that learns

Browse pgsql-hackers by date

  From Date Subject
Next Message Kai-Uwe Sattler 2006-10-13 18:49:05 index advisor
Previous Message Peter Eisentraut 2006-10-13 18:40:42 Re: ./configure argument checking