Redundant filter in index scan with a bool column

From: Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Redundant filter in index scan with a bool column
Date: 2019-01-16 11:39:53
Message-ID: 4f17bffb-3561-6460-aad8-e39d974cd01a@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

Consider this query plan:

create table t (i int, b bool);
create index on t(i, b);
set enable_bitmapscan to off;
explain select * from t where i = 300 and b;

                               QUERY PLAN
-------------------------------------------------------------------------
 Index Only Scan using t_i_b_idx on t  (cost=0.15..24.27 rows=6 width=5)
   Index Cond: ((i = 300) AND (b = true))
   Filter: b

The filter is not needed, why is it there? Turns out we can't recognize
that the restriction clause 'b' and the index clause 'b = true' are
equivalent. My first reaction was to patch operator_predicate_proof to
handle this case, but there is a more straightforward way: mark the
expanded index clause as potentially redundant when it is generated in
expand_indexqual_conditions. There is already RestrictInfo.parent_ec
that is used to mark redundant EC-derived join clauses. The patch
renames it to rinfo_parent and uses it to mark the expanded index
clauses. Namely, for both the expanded and the original clause,
rinfo_parent points to the original clause or its generating EC, if set.
The name is no good -- the original clause is not a parent of itself,
after all. I considered something like redundancy_tag, but some places
actually use the fact that it points to the generating EC, so I don't
like this name either.

What do you think?

--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Attachment Content-Type Size
0001-Recognize-that-an-expanded-bool-index-clause-is-e-v1.patch text/x-patch 17.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Arthur Zakirov 2019-01-16 11:42:44 Re: [PROPOSAL] Shared Ispell dictionaries
Previous Message Etsuro Fujita 2019-01-16 11:30:41 Re: de-deduplicate code in DML execution hooks in postgres_fdw