On Thu, May 31, 2012 at 1:01 AM, Merlin Moncure <mmoncure@gmail.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