Re: Unused index influencing sequential scan plan
От
Tom Lane
Тема
Re: Unused index influencing sequential scan plan
Дата
Msg-id
293.1350579133@sss.pgh.pa.us
Ответ на
Re: Unused index influencing sequential scan plan (Thom Brown)
Список
Дерево обсуждения
Unused index influencing sequential scan plan Thom Brown <thom@linux.com>
Re: Unused index influencing sequential scan plan Tom Lane <tgl@sss.pgh.pa.us>
Re: Unused index influencing sequential scan plan Thom Brown <thom@linux.com>
Re: Unused index influencing sequential scan plan Tom Lane <tgl@sss.pgh.pa.us>
Re: Unused index influencing sequential scan plan Thom Brown <thom@linux.com>
Re: [PERFORM] Unused index influencing sequential scan plan Thom Brown <thom@linux.com>
Re: Unused index influencing sequential scan plan Peter Geoghegan <peter@2ndquadrant.com>
Re: Unused index influencing sequential scan plan Tom Lane <tgl@sss.pgh.pa.us>
Re: Unused index influencing sequential scan plan Thom Brown <thom@linux.com>
Re: Unused index influencing sequential scan plan Thom Brown <thom@linux.com>
Re: Unused index influencing sequential scan plan Peter Geoghegan <peter@2ndquadrant.com>
Re: Unused index influencing sequential scan plan Thom Brown <thom@linux.com>
Thom Brown writes: > On 18 October 2012 17:44, Tom Lane wrote: >> Thom Brown writes: >>> And as a side note, how come it's impossible to get the planner to use >>> an index-only scan to satisfy the query (disabling sequential and >>> regular index scans)? >> Implementation restriction - we don't yet have a way to match index-only >> scans to expressions. > Ah, I suspected it might be, but couldn't find notes on what scenarios > it's yet to be able to work in. Thanks. I forgot to mention that there is a klugy workaround: add the required variable(s) as extra index columns. That is, create index i on t (foo(x), x); The planner isn't terribly bright about this, but it will use that index for a query that only requires foo(x), and it won't re-evaluate foo() (though I think it will cost the plan on the assumption it does :-(). regards, tom lane
В списке pgsql-performance по дате отправления