From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers list" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: There's random access and then there's random access |
Date: | 2007-12-02 21:43:14 |
Message-ID: | 87aboshix9.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> Recently there was a post on -performance about a particular case where
>> Postgres doesn't make very good use of the I/O system. This is when you try to
>> fetch many records spread throughout a table in random order.
>
>> http://archives.postgresql.org/pgsql-performance/2007-12/msg00005.php
>
> Since the OP in that thread has still supplied zero information
> (no EXPLAIN, let alone ANALYZE, and no version info), it's pure
> guesswork as to what his problem is.
Sure, consider it a hypothetical which needs further experimentation. That's
part of why I ran (and will rerun) those synthetic benchmarks to test whether
posix_fadvise() actually speeds up subsequent reads on a few operating
systems. Surely any proposed patch will have to prove itself on empirical
grounds too.
I could swear this has been discussed in the past too. I seem to recall Luke
disparaging Postgres on the same basis but proposing an immensely complicated
solution. posix_fadvise or using libaio in a simplistic fashion as a kind of
fadvise would be fairly lightweight way to get most of the benefit of the more
complex solutions.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
From | Date | Subject | |
---|---|---|---|
Next Message | Dragan Zubac | 2007-12-02 23:54:57 | Re: [HACKERS] Stored procedure issue |
Previous Message | Usama Dar | 2007-12-02 20:39:14 | Re: [HACKERS] Stored procedure issue |