From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | "Robins Tharakan" <tharakan(at)gmail(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: count * performance issue |
Date: | 2008-03-11 03:11:27 |
Message-ID: | dcc563d10803102011i1749c2ccy9df76c99a18b060b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Mar 10, 2008 at 7:57 PM, Robins Tharakan <tharakan(at)gmail(dot)com> wrote:
> 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
It really depends on the distribution of the null / not nulls in the
table. If it's 50/50 there's no advantage to using the index, as you
still have to check visibility info in the table itself.
OTOH, if NULL (or converserly not null) are rare, then yes, the index
can help. I.e. if 1% of the tuples are null, the select count(*) from
table where field is null can use the index efficiently.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2008-03-11 04:14:32 | Re: UPDATE 66k rows too slow |
Previous Message | Joshua D. Drake | 2008-03-11 03:08:44 | Re: count * performance issue |