Re: [PERFORM] DELETE vs TRUNCATE explanation

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PERFORM] DELETE vs TRUNCATE explanation
Дата
Msg-id CA+TgmoYnqPf03rYJo3G6dMrqShQF2iMtfpYBPgWdxtEdacaX-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PERFORM] DELETE vs TRUNCATE explanation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PERFORM] DELETE vs TRUNCATE explanation  (Tom Lane <tgl@sss.pgh.pa.us>)
Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Jul 16, 2012 at 3:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> At any rate, I'm somewhat less convinced that the split was a good
>> idea than I was when we did it, mostly because we haven't really gone
>> anywhere with it subsequently.
>
> BTW, while we are on the subject: hasn't this split completely broken
> the statistics about backend-initiated writes?

Yes, it seems to have done just that.  The comment for
ForwardFsyncRequest is a few bricks short of a load too:
* Whenever a backend is compelled to write directly to a relation* (which should be seldom, if the checkpointer is
gettingits job done),* the backend calls this routine to pass over knowledge that the relation* is dirty and must be
fsync'dbefore next checkpoint.  We also use this* opportunity to count such writes for statistical purposes.
 

Line 2 seems to have been mechanically changed from "background
writer" to "checkpointer", but of course it should still say
"background writer" in this case.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PERFORM] DELETE vs TRUNCATE explanation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PERFORM] DELETE vs TRUNCATE explanation