Re: index paths and enable_indexscan - Mailing list pgsql-hackers

From Tom Lane
Subject Re: index paths and enable_indexscan
Date
Msg-id 17563.1586874050@sss.pgh.pa.us
Whole thread Raw
In response to Re: index paths and enable_indexscan  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: index paths and enable_indexscan  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Amit Langote <amitlangote09@gmail.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



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: index paths and enable_indexscan
Next
From: Tom Lane
Date:
Subject: Re: Poll: are people okay with function/operator table redesign?