Re: BUG #15408: Postgresql bad planning with multicolumn gist and search with empty results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: acamargo(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15408: Postgresql bad planning with multicolumn gist and search with empty results
Date: 2018-09-27 14:03:31
Message-ID: 1818.1538057011@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

=?utf-8?q?PG_Bug_reporting_form?= <noreply(at)postgresql(dot)org> writes:
> As seen in the explain results, when I search for non-existent values of n2,
> the plan changes on Index condition used, giving poor plans. None of this
> plan differences appear if the index is btree. It seems something gist
> related, and I need to use gist due to PostGIS functions.

I don't have time to dig in the code right now, but my recollection is
that btcostestimate() has fairly detailed modeling of the behavior of
queries that constrain only some columns of an index, eg it understands
that "col1 = constant" is much cheaper to scan than "col2 = constant".
On the other hand, gistcostestimate() has no such modeling and assumes
that a constraint on a lower-order column is worth the same as one on
the first column.

This is partially due to lack of effort put into that function, but I seem
to recall being told that GIST was not as sensitive to column ordering
as btree, too. Your results indicate otherwise :-(

Depending on what other queries you use, maybe an adequate workaround
would be to switch the two columns of the index.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alex Pires de Camargo 2018-09-27 19:54:55 Re: BUG #15408: Postgresql bad planning with multicolumn gist and search with empty results
Previous Message Tom Lane 2018-09-27 13:47:19 Re: BUG #15407: [minor] build depends on $MAKELEVEL being 0 at top Makefile