Re: So, is COUNT(*) fast now?

----- Цитат от Tom Lane (tgl@sss.pgh.pa.us), на 22.10.2011 в 19:19 ----- <br /><br />> Andres Freund  writes: <br
/>>>On Saturday, October 22, 2011 05:20:26 PM Tom Lane wrote: <br />>>> Huh? In the case he's
complainingabout, the index is all in RAM. <br />>>> Sequentiality of access is not an issue (at least not at
thepage <br />>>> level --- within a page I suppose there could be cache-line effects). <br />> <br
/>>>I was talking about L2/L3 caches... <br />> <br />> Yeah, but unless you think cache lines cross page
boundaries(and we do <br />> take pains to align the buffers on 8K addresses), there's not going to <br />> be
anysequentiality effect. Even if there were, it would only apply <br />> if the pages chanced to be adjacent in the
bufferarray, and there is no <br />> reason to expect that to be the case, for either seqscans or indexscans. <br
/>><br />> regards, tom lane <br /><br />I worked on in-memory hash stables of parrot project. It is not the same
as<br />btrees but the structure and memory layout are not that different - tupples are <br />going into pages etc. <br
/><br/>I have benchmarked iterating over such hash tables - sequential scan <br />of the same table comes 20-30% faster
thanscan ordered by the hash value <br />of the key. And this is overhead only of CPU cache lines - the numbers of <br
/>instructionsexecuted on the processor are pretty much the same (counted by <br />valgrind). <br /><br />So I do think
thatif we have sequential scan of indexes (physical order) it <br />will help even when all the data is in the
buffercache.<br /><br />Best regards <br /><br />-- <br />Luben Karavelov