From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: planner doesn't use bitmap index |
Date: | 2015-10-29 18:20:29 |
Message-ID: | 2036.1446142829@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> -- I was surprised, so following query can use index
> postgres=# explain select a from test2 where a at time zone
> 'America/Santiago' >= now() at time zone 'America/Santiago' ;
> QUERY
> PLAN
>
> Index Only Scan using test2_a_idx on test2 (cost=0.13..12.18 rows=1
> width=8)
> Filter: (timezone('America/Santiago'::text, a) >=
> timezone('America/Santiago'::text, now()))
> (2 rows)
This plan isn't actually "using" the index in any meaningful way; it's
applying the where condition as a filter. It happens to be sane to use
the index as a dumb data source, because it can be an index-only scan, and
that might (if you're lucky and don't hit too many recheckable rows) be
cheaper than a seqscan. But we don't consider plain indexscans as worth
the trouble to consider in such cases, because a full-table plain
indexscan can never beat a seqscan, either in the planner's cost model or
in reality.
> why, the index isn't used in this case?
> postgres=# explain select a,b from test2 where a at time zone
> 'America/Santiago' >= now() at time zone 'America/Santiago' ;
Can't be an index-only scan because of the use of b, so there's no
possible way that this can be better than a seqscan.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-10-29 18:25:14 | Re: ALTER ... OWNER TO ... vs. ALTER DEFAULT PRIVILEGES |
Previous Message | Alexander Korotkov | 2015-10-29 17:18:49 | Re: Move PinBuffer and UnpinBuffer to atomics |