From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Gregory Stark <stark@enterprisedb.com>
Cc: ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>
Cc: Postgres <pgsql-hackers@postgresql.org>
Subject: Re: posix_fadvise v22
Date: Sun, 11 Jan 2009 14:14:50 -0500
Message-ID: <1098.1231701290@sss.pgh.pa.us> (raw)
In-Reply-To: <603c8f070901011843p121e40afu35c4a7bdc51c051c@mail.gmail.com>
References: <FDDBA24E-FF4D-4654-BA75-692B3BA71B97@enterprisedb.com>
<8347.1229012970@sss.pgh.pa.us>
<4136ffa0812110911x4914a951o6ca502879e3dede7@mail.gmail.com>
<87k5a6tmy7.fsf@oxford.xeocode.com>
<603c8f070901011230t1afa6644racb715b975078054@mail.gmail.com>
<10658.1230843315@sss.pgh.pa.us>
<603c8f070901011843p121e40afu35c4a7bdc51c051c@mail.gmail.com>
"Robert Haas" <robertmhaas@gmail.com> writes:
> OK, here's an update of Greg's patch with the runtime configure test
> ripped out, some minor documentation tweaks, and a few unnecessary
> whitespace diff hunks quashed. I think this is about ready for
> committer review.
I've started to look through this, and the only part I seriously don't
like is the nbtsearch.c changes. I've got three complaints about that:
* Doing it inside the index AMs is wrong, or at the very least forces
us to do it over for each index AM (which the patch fails to do).
* As coded, it generates prefetch bursts that are much too large and too
widely spaced to be effective, not to mention that they entirely
ignore the effective_io_concurrency control knob as well as the order
in which the pages will actually be needed. I wonder now whether
Robert's inability to see any benefit came because he was testing
indexscans and not bitmap scans.
* It's only accidental that it's not kicking in during a bitmap
indexscan and bollixing up the much-more-carefully-written
nodeBitmapHeapscan prefetch logic.
What I intend to do over the next day or so is commit the prefetch
infrastructure and the bitmap scan prefetch logic, but I'm bouncing the
indexscan part back for rework. I think that it should be implemented
in or near index_getnext() and pay attention to
effective_io_concurrency.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, stark@enterprisedb.com, itagaki.takahiro@oss.ntt.co.jp
Subject: Re: posix_fadvise v22
In-Reply-To: <1098.1231701290@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox