Jesper Krogh <jesper@xxxxxxxx> writes: > On 2010-10-12 19:07, Tom Lane wrote: >> Anyway, if anyone is hot to make COUNT(*) faster, that's where to look. > Just having 32 bytes bytes of "payload" would more or less double > you time to count if I read you test results correctly?. .. and in the > situation where diskaccess would be needed .. way more. > Dividing by pg_relation_size by the amout of tuples in our production > system I end up having no avg tuple size less than 100bytes. Well, yeah. I deliberately tested with a very narrow table so as to stress the per-row CPU costs as much as possible. With any wider table you're just going to be I/O bound. > .. without having complete insigt.. a visibillity map that could be used in > conjunction with indices would solve that. What the cost would be > of maintaining it is also a factor. I'm less than convinced that that approach will result in a significant win. It's certainly not going to do anything to convert COUNT(*) into an O(1) operation, which frankly is what the complainants are expecting. There's basically no hope of solving the "PR problem" without somehow turning COUNT(*) into a materialized-view reference. We've discussed that in the past, and know how to do it in principle, but the complexity and distributed overhead are daunting. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
