Re: Proposal: scan key push down to heap [WIP]
От | Tom Lane |
---|---|
Тема | Re: Proposal: scan key push down to heap [WIP] |
Дата | |
Msg-id | 27862.1476363536@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal: scan key push down to heap [WIP] (Dilip Kumar <dilipbalaut@gmail.com>) |
Список | pgsql-hackers |
Dilip Kumar <dilipbalaut@gmail.com> writes: > On Thu, Oct 13, 2016 at 6:05 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> I seriously doubt that this should EVER be supported for anything >> other than "var op const", and even then only for very simple >> operators. > Yes, with existing key push down infrastructure only "var op const", > but If we extend that I think we can cover many other simple > expressions, i.e I think it is a mistake to let this idea drive any additional complication of the ScanKey data structure. That will have negative impacts on indexscan performance, not to mention require touching quite a lot of unrelated code. And as Robert points out, we do not want to execute anything expensive while holding the buffer LWLock. >> Part of the trick if we want to make this work is going to be figuring >> out how we'll identify which operators are safe. > Yes, I agree that's the difficult part. Can't we process full qual > list and decide decide the operator are safe or not based on their > datatype ? Possibly restricting it to builtin, immutable functions on non-toastable data types would do. Or for more safety, only allow pass-by-value data types. But I have a feeling that there might still be counterexamples. regards, tom lane
В списке pgsql-hackers по дате отправления: