Re: more anti-postgresql FUD

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: more anti-postgresql FUD
Дата
Msg-id 1160765146.31966.283.camel@dogma.v10.wvs
обсуждение исходный текст
Ответ на Re: more anti-postgresql FUD  ("Jim C. Nasby" <jim@nasby.net>)
Список pgsql-general
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@sss.pgh.pa.us> wrote:
> > >Martijn van Oosterhout <kleptog@svana.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


В списке pgsql-general по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: A query planner that learns
Следующее
От: "J S B"
Дата:
Сообщение: Re: Backup DB not getting connected