Re: There's random access and then there's random access

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: There's random access and then there's random access
Дата
Msg-id 87aboshix9.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: There's random access and then there's random access  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: There's random access and then there's random access  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.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'sPostgreSQL training!
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Usama Dar"
Дата:
Сообщение: Re: Stored procedure issue
Следующее
От: Dragan Zubac
Дата:
Сообщение: Re: Stored procedure issue