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

Re: [PATCH] Prefetch index pages for B-Tree index scans

From: John Lumby <johnlumby(at)hotmail(dot)com>
To: <bruce(at)momjian(dot)us>
Cc: Claudio Freire <klaussfreire(at)gmail(dot)com>, Greg Smith<greg(at)2ndquadrant(dot)com>, pgsql hackers <pgsql-hackers(at)postgresql(dot)org>, Cédric Villemain <cedric(at)2ndquadrant(dot)com>
Subject: Re: [PATCH] Prefetch index pages for B-Tree index scans
Date: 2012-11-06 13:53:03
Message-ID: COL116-W27CCF26B2D4D859F192289A36B0@phx.gbl (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bruce Momjian wrote:
> On Fri, Nov 2, 2012 at 09:59:08AM -0400, John Lumby wrote:
> > However,    the OP describes an implementation based on libaio.
> > Today what we have (for linux) is librt,  which is quite different.
> Well, good thing we didn't switch to using libaio, now that it is gone.
Yes,  I think you are correct.    Although I should correct myself about
status of libaio -  it seems many distros continue to provide it and at least
one other popular database (MySQL) uses it,   but as far as I can tell
the content has not been updated by the original authors for around 10 years.
That is perhaps not surprising since it does very little other than wrap
the linux kernel syscalls.

Set against the CPU-overhead disadvantage of librt,  I think the three
main advantages of librt vs libaio/kernel-aio for postgresql are :
  .   posix standard,  and probably easier to provide very similar
      implementation on windows  (I see at least one posix aio lib for windows)
  .   no restrictions on the way files are accessed  (kernel-aio imposes restrictions
      on open() flags and buffer alignment etc)
  .   it seems (from the recent postings about the earlier attempt to implement
      async io using libaio) that the posix threads style lends itself better to 
      fitting in with the postgresql backend model.



In response to

pgsql-hackers by date

Next:From: DenisDate: 2012-11-06 14:16:14
Subject: Re: [HACKERS] pg_dump and thousands of schemas
Previous:From: md@rpzdesign.comDate: 2012-11-06 12:34:44
Subject: File Corruption recovery

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