Re: I/O on select count(*)
От | Alvaro Herrera |
---|---|
Тема | Re: I/O on select count(*) |
Дата | |
Msg-id | 20080515144106.GA8221@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: I/O on select count(*) (Greg Smith <gsmith@gregsmith.com>) |
Ответы |
Re: I/O on select count(*)
|
Список | pgsql-performance |
Greg Smith escribió: > On Thu, 15 May 2008, Pavan Deolasee wrote: > >> I had suggested in the past that whenever we set hint bits for a tuple, >> we should check all other tuples in the page and set their hint bits >> too to avoid multiple writes of the same page. I guess the idea got >> rejected because of lack of benchmarks to prove the benefit. > > From glancing at http://www.postgresql.org/docs/faqs.TODO.html I got the > impression the idea was to have the background writer get involved to > help with this particular situation. The problem is that the bgwriter does not understand about the content of the pages it is writing -- they're opaque pages for all it knows. So it cannot touch the hint bits. I agree with Pavan that it's likely that setting hint bits in batches instead of just for the tuple being examined is a benefit. However, it's perhaps not so good to be doing it in a foreground process, because you're imposing extra cost to the client queries which we want to be as fast as possible. Perhaps the thing to do is have a "database-local bgwriter" which would scan pages and do this kind of change ... a different kind of process to be launched by autovacuum perhaps. If we had the bitmask in a separate map fork, this could be cheap. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-performance по дате отправления: