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
Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation) |
Список | 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 по дате отправления: