Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group