Pavan Deolasee wrote: > On 1/26/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > > >Heikki Linnakangas wrote: > >> I'd like to see still more evidence that it's a problem before we start > >> changing that piece of code. It has served us well for years. > > > >So the TODO could be "investigate whether caching pg_clog and/or > >pg_subtrans in local memory can be useful for vacuum performance". > > > As Heikki suggested, we should also investigate the same for normal > backends as well.
Maybe. An idea that comes to mind is to never cache the latest page, since it'll most likely result in extra reads anyway because there'll be a lot of IN_PROGRESS transactions. Problem to solve: how much memory to dedicate to this? Could we mmap() portions of the pg_clog segment, so that the page could be shared across backends instead of allocating them for each? > It would also be interesting to investigate whether early setting of > hint bits can reduce subsequent writes of blocks. A typical case would > be a large table being updated heavily for a while, followed by SELECT > queries. The SELECT queries would set hint bits for the previously > UPDATEd tuples (old and new versions) and thus cause subsequent > writes of those blocks for what could have been read-only queries. This has been suggested before, but I don't see how this could work. How does the UPDATE transaction go back to the pages it wrote to update the hint bits, _after_ it committed? Maybe have the bgwriter update hint bits as it evicts pages out of the cache? It could result in pg_clog read traffic for each page that needs eviction; not such a hot idea. I don't see how this is related to the above proposal though. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
