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:34:10
Message-ID: 18423.1586874850@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 was really thinking of this in terms of planner effort, which for
> creating an index path is more than creating sequential path, although
> sure the payoff can be great. That is, I want the planner to avoid
> creating index paths *to save cycles*, but see no way of making that
> happen. I was thinking disabling enable_indexscan would do the trick.

I think that's completely misguided, because in point of fact nobody
is going to care about the planner's performance with enable_indexscan
turned off. It's not an interesting production case.

All of these enable_xxx switches exist just for debug purposes, and so
the right way to think about them is "what's the simplest, least
bug-prone, lowest-maintenance way to get the effect?".

Likewise, I don't actually much care what results you get if you turn
off *all* of them. It's not a useful case to spend our effort on.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Asif Rehman 2020-04-14 14:36:58 Re: WIP/PoC for parallel backup
Previous Message Tom Lane 2020-04-14 14:29:04 Re: Poll: are people okay with function/operator table redesign?