hint bit cache v6

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: hint bit cache v6
Date: 2011-05-13 19:48:36
Message-ID: BANLkTinr1h1+rKX1UOukn-rAONBTEHQvew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

what's changed:
*) as advertised, i'm no longer bothering to cache invalid bits. hint
bit i/o via rollbacked transactions is not a big deal IMNSHO, so they
will work as they have always done.
*) all the tuple visibility routines are now participating in the cache
*) xmax commit bits are now being cached, not just xmin. this
prevents hint bit i/o following deletes.
*) juggled the cache interaction a bit so the changes to the
visibility routines could be a lot more surgical. specifically, I
reverted SetHintBits() to return void and put the cache adjustment
inside 'SetHintBitsCache()' which sets the bits, dirties, and adjusts
the cache. SetHintBitsNonDirty() only sets the bits without dirtying
the page, and is called when you get a cache hit.
*) various minor cleanups, decided to keep pageindex as type
TransactionId since that's what clog does.
*) made a proper init function, put cache data into
CacheMemoryContext, and moved the cache data pointer references into
the page structure

performance testing done:
*) select only pgbench and standard i/o pgbech tests don't show
performance difference within statistical noise.

The test I need to do, a cache and clog thrashing test, I haven't
found a clean way to put together yet. I'm really skeptical that any
problems will show up there. That said, I am satisfied the patch does
what it is supposed to do -- eliminates hint bit i/o without for cases
where it is a big headache without penalizing other cases. Anyone
that would like to comment on the technique or other points of the
patch please do so (otherwise it's time for the 'fest).

merlin

Attachment Content-Type Size
hbache_v6.patch application/octet-stream 24.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-05-13 19:52:40 Re: Foreign table permissions and cloning
Previous Message Tom Lane 2011-05-13 17:13:23 Re: Debug contrib/cube code