Re: count * performance issue
| От | Robins Tharakan |
|---|---|
| Тема | Re: count * performance issue |
| Дата | |
| Msg-id | 36af4bed0803101957u6078127fq78dc3384fe78de5d@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: count * performance issue (Greg Smith <gsmith@gregsmith.com>) |
| Ответы |
Re: count * performance issue
Re: count * performance issue Re: count * performance issue Re: count * performance issue |
| Список | pgsql-performance |
Hi,
I have been reading this conversation for a few days now and I just wanted to ask this. From the release notes, one of the new additions in 8.3 is (Allow col IS NULL to use an index (Teodor)).
Sorry, if I am missing something here, but shouldn't something like this allow us to get a (fast) accurate count ?
SELECT COUNT(*) from table WHERE indexed_field IS NULL
+
SELECT COUNT(*) from table WHERE indexed_field IS NOT NULL
Robins Tharakan
I have been reading this conversation for a few days now and I just wanted to ask this. From the release notes, one of the new additions in 8.3 is (Allow col IS NULL to use an index (Teodor)).
Sorry, if I am missing something here, but shouldn't something like this allow us to get a (fast) accurate count ?
SELECT COUNT(*) from table WHERE indexed_field IS NULL
+
SELECT COUNT(*) from table WHERE indexed_field IS NOT NULL
Robins Tharakan
---------- Forwarded message ----------
From: Greg Smith <gsmith@gregsmith.com>
Date: Tue, Mar 11, 2008 at 4:31 AM
Subject: Re: [PERFORM] count * performance issue
To: Joe Mirabal <jmmirabal@gmail.com>
Cc: pgsql-performance@postgresql.org
utilizing the index to find a useful subset? What do you get out of
EXPLAIN ANALZYE on the query?
In order for indexes to be helpful a couple of things need to happen:
1) They have to be structured correctly to be useful
2) There needs to be large enough settings for shared_buffes and
effective_cache_size that the database things it can use them efficiently
3) The tables involved need to be ANALYZEd to keep their statistics up to
date.
The parameters to run a 400GB *table* are very different from the
defaults; if you want tuning suggestions you should post the non-default
entries in your postgresql.conf file from what you've already adjusted
along with basic information about your server (PostgreSQL version, OS,
memory, disk setup).
> We in our warehouse use the count(*) as our verification of counts by
> day/month's etc
If you've got a database that size and you're doing that sort of thing on
it, you really should be considering partitioning as well.
From: Greg Smith <gsmith@gregsmith.com>
Date: Tue, Mar 11, 2008 at 4:31 AM
Subject: Re: [PERFORM] count * performance issue
To: Joe Mirabal <jmmirabal@gmail.com>
Cc: pgsql-performance@postgresql.org
On Mon, 10 Mar 2008, Joe Mirabal wrote:
> 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.
Are you sure the form of "select count(*)" you're using is actually> 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.
utilizing the index to find a useful subset? What do you get out of
EXPLAIN ANALZYE on the query?
In order for indexes to be helpful a couple of things need to happen:
1) They have to be structured correctly to be useful
2) There needs to be large enough settings for shared_buffes and
effective_cache_size that the database things it can use them efficiently
3) The tables involved need to be ANALYZEd to keep their statistics up to
date.
The parameters to run a 400GB *table* are very different from the
defaults; if you want tuning suggestions you should post the non-default
entries in your postgresql.conf file from what you've already adjusted
along with basic information about your server (PostgreSQL version, OS,
memory, disk setup).
> We in our warehouse use the count(*) as our verification of counts by
> day/month's etc
it, you really should be considering partitioning as well.
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
В списке pgsql-performance по дате отправления: