Re: Slow count(*) again...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




I guess I have to comment here again and point out that while I am having this issue with text searches, I avoid using count(*) in such cases, I just use
next and previous links.

Unfortunately sometimes you got to do an ORDER BY on search results, and then all the rows got to be read...

Where the real problem (for me) is that when someone
searches a date or time range. My application keeps track of huge

Have you tried CLUSTER ?

Also, it is sad to say, but if you need an engine able to use index-only scans which would fit this type of query, replicate the table to MyISAM. Unfortunately, the MySQL optimizer is really not so smart about complex reporting queries (no hash joins, no hash aggregates) so if you don't have a multicolumn index covering that you can use for index-only scan in your query, you'll get either a really huge sort or a really nasty nested loop index scan...

--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux