Re: Slow count(*) again...
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jesper Krogh <jesper@krogh.cc>
Cc: Mladen Gogala <mladen.gogala@vmsinfo.com>,
"david@lang.hm" <david@lang.hm>, Craig Ringer <craig@postnewspapers.com.au>, Vitalii Tymchyshyn <tivv00@gmail.com>, "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Date: 2010-10-12T18:58:13Z
Lists: pgsql-hackers, pgsql-performance
Jesper Krogh <jesper@krogh.cc> 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