On Mon, Mar 10, 2008 at 1:54 PM, Joe Mirabal <jmmirabal@xxxxxxxxx> wrote: > Gregory, > > I just joined this listserv and was happy to see this posting. I have a > 400GB table that I have indexed (building the index took 27 hours) , Loading > the table with 10 threads took 9 hours. I run queries on the data nad get > immediate max and min as well as other aggrgate functions very quickly, > however a select count(*) of the table takes forever usually nearly an hour > or more. > > Do you have any tuning recommendations. We in our warehouse use the > count(*) as our verification of counts by day/month's etc and in Netezza its > immediate. I tried by adding oids. BUT the situation I learned was that > adding the oids in the table adds a significasnt amount of space to the data > AND the index. Yeah, this is a typical problem people run into with MVCC databases to one extent or another. PostgreSQL has no native way to just make it faster. However, if it's a table with wide rows, you can use a lookup table to help a bit. Have a FK with cascading deletes from the master table to a table that just holds the PK for it, and do count(*) on that table. Otherwise, you have the trigger solution mentioned previously. Also, if you only need an approximate count, then you can use the system tables to get that with something like select reltuples from pg_class where relname='tablename'; after an analyze. It won't be 100% accurate, but it will be pretty close most the time. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
