Re: Visibility map and hint bits
От | Merlin Moncure |
---|---|
Тема | Re: Visibility map and hint bits |
Дата | |
Msg-id | BANLkTimXw11t9Afo5SZhsrn_sQYKERdLBQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Visibility map and hint bits ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Visibility map and hint bits
|
Список | pgsql-hackers |
On Thu, May 5, 2011 at 2:00 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Merlin Moncure <mmoncure@gmail.com> wrote: > >> a small cache that remembers the commit/cancel status of recently >> seen transactions. > > How is that different from the head of the clog SLRU? several things: *) any slru access requires lock (besides the lock itself, you are spending cycles in critical path) *) cache access happens at different stage of processing in HeapTupleSatisfiesMVCC: both TransactionIdIsCurrentTransactionId and TransactionIdIsInProgress have to be checked first. Logically, it's extension of hint bit check itself, not expansion of lower levels of caching *) in tqual.c you can sneak in some small optimizations like only caching the bit if it's known good in the WAL (XlogNeedsFlush). That way you don't need to keep checking it over and over for the same trasaction *) slru level accesses happen too late to give much benefit: I can't stress enough how tight HeapTupleSatisfiesMVCC is. On my workstation VM, each non inline function call shows up measurably in profiling. I think anything you do here has to be inline, hand rolled, and very tight (you can forget anything around dynahash). Delegating the cache management to transam or (even worse) slru level penalizes some workloads non-trivially. merlin
В списке pgsql-hackers по дате отправления: