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
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? |