Sequential Scan Read-Ahead
От | Curt Sampson |
---|---|
Тема | Sequential Scan Read-Ahead |
Дата | |
Msg-id | Pine.NEB.4.43.0204241627100.439-100000@angelic.cynic.net обсуждение исходный текст |
Ответ на | Re: Index Scans become Seq Scans after VACUUM ANALYSE (Lincoln Yeoh <lyeoh@pop.jaring.my>) |
Ответы |
Re: Sequential Scan Read-Ahead
|
Список | pgsql-hackers |
At 12:41 PM 4/23/02 -0400, Bruce Momjian wrote: >This is an interesting point, that an index scan may fit in the cache >while a sequential scan may not. If so, I would expect that the number of pages read is significantly smaller than it was with a sequential scan. If that's the case, doesn't that mean that the optimizer made the wrong choice anyway? BTW, I just did a quick walk down this chain of code to see what happens during a sequential scan: access/heap/heapam.c storage/buffer/bufmgr.c storage/smgr/smgr.c storage/smgr/md.c and it looks to me like individual reads are being done in BLKSIZE chunks, whether we're scanning or not. During a sequential scan, I've heard that it's more efficient to read in multiples of your blocksize, say, 64K chunks rather than 8K chunks, for each read operation you pass to the OS. Does anybody have any experience to know if this is indeed the case? Has anybody ever added this to postgresql and benchmarked it? Certainly if there's a transaction based limit on disk I/O, as well as a throughput limit, it would be better to read in larger chunks. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're alllight. --XTC
В списке pgsql-hackers по дате отправления: