From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Optimizer misses big in 10.4 with BRIN index |
Date: | 2018-07-25 16:50:06 |
Message-ID: | a4db9fc9-8e4c-1403-5d2e-72ecf34443ad@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 07/25/2018 03:58 PM, Arcadiy Ivanov wrote:
> -> Bitmap Index Scan on tradedate_idx
> (cost=0.00..231.96 rows=3377106 width=0) (actual time=4.500..4.500
> rows=23040 loops=1)
> Index Cond: ((((data_table.data ->>
> 'tradeDate'::text))::numeric >= '1531267200'::numeric) AND
> (((data_table.data ->> 'tradeDate'::text))::numeric <=
> '1531353600'::numeric))
My guess is this is the root cause - the estimated number of rows is
much higher than in practice (3377106 vs. 23040), so at the end the
seqscan is considered to be slightly cheaper and wins. But the actual
row count is ~150x lower, making the bitmap index scan way faster.
IMHO you'll need to find a way to improve the estimates, which may be
difficult. The first thing I'd try is creating an expression index on
the expression you use in the WHERE clause. Something like
CREATE INDEX ON data_table (((data_table.data ->>
'tradeDate'::text))::numeric);
And then ANALYZE the table again ...
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Cynthia Shang | 2018-07-25 17:24:08 | Re: Allow COPY's 'text' format to output a header |
Previous Message | Alvaro Herrera | 2018-07-25 16:41:59 | Re: no partition pruning when partitioning using array type |