PFC <[EMAIL PROTECTED]> writes:
> You can also read 'internal not yet developed postgres cache manager'
> instead of OS if you don't feel like talking kernel developers into
> implementing this thing.
It exists already, it's called aio.
But there are a *lot* of details you skipped over.
In the 'wishful hand waving' department :
read index -> determine (tuple id,page) to hit in table -> for each of
these, tell the OS 'I'm gonna need these' via a NON BLOCKING call. Non
blocking because you feed the information to the OS as you read the index,
streaming it.
Meanwhile, th
In the last exciting episode, [EMAIL PROTECTED] ("Merlin Moncure") wrote:
>> It seems inevitable that Postgres will eventually eliminate that
>> redundant layer of buffering. Since mmap is not workable, that
>> means using O_DIRECT to read table and index data.
>
> What about going the other way an
>Josh Berkus wrote:
>> Now you can see why other DBMSs don't use the OS disk cache. There's
>> other
>> issues as well; for example, as long as we use the OS disk cache, we
>can't
>> eliminate checkpoint spikes, at least on Linux. No matter what we do
>with
>> the bgwriter, fsyncing the OS disk c
Josh Berkus writes:
> Why is mmap not workable?It would require far-reaching changes to our
> code
> -- certainly -- but I don't think it can be eliminated from consideration.
Fundamentally because there is no facility for being notified by the OS before
a page is written to disk. And the
Josh Berkus wrote:
> Now you can see why other DBMSs don't use the OS disk cache. There's
> other
> issues as well; for example, as long as we use the OS disk cache, we
can't
> eliminate checkpoint spikes, at least on Linux. No matter what we do
with
> the bgwriter, fsyncing the OS disk cache cau
Josh Berkus writes:
> Why is mmap not workable?
We can't control write order. There are other equally bad problems,
but that one alone eliminates it from consideration. See past discussions.
regards, tom lane
---(end of broadcast)---
Tom, Greg, Merlin,
> But for example,
> if our buffer management algorithm recognizes an index page as being
> heavily hit and therefore keeps it in cache for a long time, then when
> it does fall out of cache you can be sure it's going to need to be read
> from disk when it's next used, because
Greg Stark wrote:
Kevin Brown <[EMAIL PROTECTED]> writes:
Ouch. Is this really a reasonable assumption? I figured the primary
use of a cursor was to fetch small amounts of data at a time from a
large table, so 10% seems extremely high as an average fetch size. Or
is the optimization based on th
> It seems inevitable that Postgres will eventually eliminate that
redundant
> layer of buffering. Since mmap is not workable, that means using
O_DIRECT
> to
> read table and index data.
What about going the other way and simply letting the o/s do all the
caching? How bad (or good) would the perf
I don't know if this would work, but if you just want to restructure your
rows, your could do this:
UPDATE table SET id = id WHERE id BETWEEN 0 AND 2;
VACUUM table;
UPDATE table SET id = id WHERE id BETWEEN 20001 AND 4;
VACUUM table;
wash, rinse,
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > 8.0, on the other hand, has a new algorithm that specifically tries to
> > protect against the shared buffers being blown out by a sequential
> > scan. But that will only help if it's the shared buffers being
> > thr
12 matches
Mail list logo
