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
|
Список | 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 по дате отправления: