Re: index paths and enable_indexscan
От
Tom Lane
Тема
Re: index paths and enable_indexscan
Дата
Msg-id
18423.1586874850@sss.pgh.pa.us
Ответ на
Re: index paths and enable_indexscan (Amit Langote)
Список
Дерево обсуждения
index paths and enable_indexscan Amit Langote <amitlangote09@gmail.com>
Re: index paths and enable_indexscan Richard Guo <guofenglinux@gmail.com>
Re: index paths and enable_indexscan Amit Langote <amitlangote09@gmail.com>
Re: index paths and enable_indexscan Andy Fan <zhihui.fan1213@gmail.com>
Re: index paths and enable_indexscan Amit Langote <amitlangote09@gmail.com>
Re: index paths and enable_indexscan Tom Lane <tgl@sss.pgh.pa.us>
Re: index paths and enable_indexscan Robert Haas <robertmhaas@gmail.com>
Re: index paths and enable_indexscan Andy Fan <zhihui.fan1213@gmail.com>
Re: index paths and enable_indexscan Amit Langote <amitlangote09@gmail.com>
Re: index paths and enable_indexscan Tom Lane <tgl@sss.pgh.pa.us>
Re: index paths and enable_indexscan Andy Fan <zhihui.fan1213@gmail.com>
Amit Langote 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
В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата: