Re: index paths and enable_indexscan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: index paths and enable_indexscan
Date: 2020-04-14 14:20:50
Message-ID: 17563.1586874050@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> I am saying that instead of building index path with disabled cost,
> just don't build it at all. A base rel will always have a sequetial
> path, even though with disabled cost if enable_seqscan = off.

Awhile back I'd looked into getting rid of disable_cost altogether
by dint of not generating disabled paths. It's harder than it
sounds. We could perhaps change this particular case, but it's
not clear that there's any real benefit of making this one change
in isolation.

Note that you can't just put a big OFF switch at the start of indxpath.c,
because enable_indexscan and enable_bitmapscan are distinct switches,
but the code to generate those path types is inextricably intertwined.
Skipping individual paths further down on the basis of the appropriate
switch would be fairly subtle and perhaps bug-prone. The existing
implementation of those switches has the advantages of being trivially
simple and clearly correct (for some value of "correct").

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-04-14 14:29:04 Re: Poll: are people okay with function/operator table redesign?
Previous Message Amit Langote 2020-04-14 14:16:27 Re: index paths and enable_indexscan