Re: Early hint bit setting

From: Ants Aasma <ants(at)cybertec(dot)at>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Early hint bit setting
Date: 2012-05-30 22:40:13
Message-ID: CA+CSw_vkL6ykSTqoes_M931fZy=J2GJVZcQrBR8i83HSV2my5g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 31, 2012 at 1:01 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> I think this is a really neat idea, and could solve a lot of problems.
>  Since you don't have to do any clog checks (you know when you commit)
> -- i think it's a win all around -- so much so that it might be worth
> seeing the worst case latency hit if you force one page out always
> before doing the socket check.  Hm, could you shave cpu cycles by just
> storing the specific offsets of the hint bit bytes you want to set, or
> is that too hacky?

Maybe even do both. By default store tuple offsets, but when the last
item was from the same page convert it to a page hinting request. I
have a specific near-realtime datawarehouse workload in mind where
bulk load is being constantly performed by smallish transactions. By
having page granularity in the buffer almost all pages could be hinted
before hitting the disk. The latency vs throughput tradeoff could
possibly be per backend tunable.

Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2012-05-30 23:07:23 Re: We're not lax enough about maximum time zone offset from UTC
Previous Message Robert Haas 2012-05-30 22:14:41 patch: avoid heavyweight locking on hash metapage