pgcluu icon indicating copy to clipboard operation
pgcluu copied to clipboard

Bug in the redundant indexes report

Open gleu opened this issue 3 years ago • 3 comments

The WHERE clause doesn't seem to be checked. Here is a quick example:

CREATE TABLE t1 (id integer);
CREATE INDEX ON t1(id) WHERE id=1;
CREATE INDEX ON t1(id) WHERE id=2;

The query used by pgcluu will find they are redundant indexes. But they aren't.

┌─[ RECORD 1 ]─────┬──────────────────────────────────────────────────────────────────────┐
│ date_trunc       │ 2022-04-11 15:00:28+02                                               │
│ current_database │ postgres                                                             │
│ contained        │ CREATE INDEX t1_id_idx1 ON public.t1 USING btree (id) WHERE (id = 2) │
│ container        │ CREATE INDEX t1_id_idx ON public.t1 USING btree (id) WHERE (id = 1)  │
└──────────────────┴──────────────────────────────────────────────────────────────────────┘

Not sure how we can fix it though.

gleu avatar Apr 11 '22 13:04 gleu

Commit 168ff82 is an attempt to fix this issue.

darold avatar Apr 11 '22 14:04 darold

OK, so that seems to be working. Though there still is a bug, which may not be related. See this (the "oh" view in the script is your updated query):

$ cat tests.sql
DROP TABLE IF EXISTS t1;
CREATE TABLE t1(id integer);
CREATE INDEX ON t1(id);
CREATE INDEX ON t1(id);
CREATE INDEX ON t1(id) WHERE id=1;
TABLE oh \gx
DROP TABLE IF EXISTS t1;
CREATE TABLE t1(id integer);
CREATE INDEX ON t1(id);
CREATE INDEX ON t1(id) WHERE id=1;
CREATE INDEX ON t1(id);
TABLE oh \gx

$ psql -f tests.sql 
DROP TABLE
Time: 4.152 ms
CREATE TABLE
Time: 2.719 ms
CREATE INDEX
Time: 9.118 ms
CREATE INDEX
Time: 8.945 ms
CREATE INDEX
Time: 8.998 ms
┌─[ RECORD 1 ]─────┬───────────────────────────────────────────────────────┐
│ date_trunc       │ 2022-04-12 07:25:33+02                                │
│ current_database │ postgres                                              │
│ contained        │ CREATE INDEX t1_id_idx1 ON public.t1 USING btree (id) │
│ container        │ CREATE INDEX t1_id_idx ON public.t1 USING btree (id)  │
└──────────────────┴───────────────────────────────────────────────────────┘

Time: 2.234 ms
DROP TABLE
Time: 3.110 ms
CREATE TABLE
Time: 2.746 ms
CREATE INDEX
Time: 9.637 ms
CREATE INDEX
Time: 9.908 ms
CREATE INDEX
Time: 9.301 ms
(0 rows)

Time: 1.029 ms

So depending on the order of creation of indexes, they will be found redundant or not.

gleu avatar Apr 12 '22 05:04 gleu

I took another look at the query, and I understand now why there's this dependency on the order of creation. Though I don't see an easy way out. The good thing is that now there is no false positive. And, as a great philosopher said, "I can live with" false negatives.

gleu avatar Apr 12 '22 07:04 gleu

Commit 8918139 fixes this issue.

darold avatar Dec 26 '22 15:12 darold