On 2011-05-11 01:54, Greg Stark wrote:<br /><blockquote cite="mid:BANLkTi=XvEA24K=LNNUg=SwyrxK-p-U0nw@mail.gmail.com"
type="cite"><prewrap="">
To be fair about 3/4 of them were actually complaining about the lack
of some global materialized cache of the aggregate value. Covering
index-only scans are only going to be a linear speedup no matter how
large the factor it's not going to turn select count(*) into a O(1)
operation.
</pre></blockquote> Actually, if we could get to count(*) into the situation of a <br /> very "thin row" today, so the
costof visibillity-testing didn't depend<br /> hugely on the width of the row any more, then we be half-<br />
way-therein terms of performance optimization. <br /><br /> If rows typically just were tuple-headers + a bit more,
thenit <br /> would be way harder to go down this road and claim good <br /> benefits. But currently the system needs
todrag in "allmost" <br /> one page pr. visibillity test from disk on "random large tables". <br /><br /> I tried to
graphthe differences of thin vs. wide rows here:<br /><a href="http://shrek.krogh.cc/%7Ejesper/visibillitytesting.pdf"
rel="nofollow"target="_top"><span>http://shrek.<b class="highlight">krogh</b>.cc/~<b class="highlight">jesper</b>/<b
class="highlight">visibillitytesting</b>.pdf</span></a><br/><a class="moz-txt-link-freetext"
href="http://postgresql.1045698.n5.nabble.com/Visibillity-testing-some-numbers-on-current-performance-td4284836.html">http://postgresql.1045698.n5.nabble.com/Visibillity-testing-some-numbers-on-current-performance-td4284836.html</a><br
/><br/> The getting the visibillitymap down to an O(n) is "on large tables"<br /> shifting to be memory based vs.
disk-basedas now. <br /><br /> Jesper (It not a goal, but it would most-likely postpone some<br /> peoples needs for
buyinga FusionIO card or similar)<br /> -- <br /> Jesper<br />
