Re: Minor code improvements to create_foreignscan_plan/ExecInitForeignScan
От | Etsuro Fujita |
---|---|
Тема | Re: Minor code improvements to create_foreignscan_plan/ExecInitForeignScan |
Дата | |
Msg-id | 56A9C025.3050603@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Minor code improvements to create_foreignscan_plan/ExecInitForeignScan (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Minor code improvements to
create_foreignscan_plan/ExecInitForeignScan
|
Список | pgsql-hackers |
On 2016/01/28 12:13, Robert Haas wrote: > On Thu, Jan 21, 2016 at 5:55 AM, Etsuro Fujita > <fujita.etsuro@lab.ntt.co.jp> wrote: >> On 2016/01/21 7:04, Alvaro Herrera wrote: >>> Etsuro Fujita wrote: >>>> >>>> On second thought, I noticed that detecting whether we see a system >>>> column >>>> that way needs more cycles in cases where the reltargetlist and the >>>> restriction clauses don't contain any system columns. ISTM that such >>>> cases >>>> are rather common, so I'm inclined to keep that code as-is. >>> Ah, I see now what you did there. I was thinking you'd have the >>> foreach(restrictinfo) loop, then once the loop is complete scan the >>> bitmapset; not scan the bitmap set scan inside the other loop. >> Ah, I got to the point. I think that is a good idea. The additional cycles >> for the worst case are bounded and negligible. Please find attached an >> updated patch. > I don't think this is a good idea. Most of the time, no system > columns will be present, and we'll just be scanning the Bitmapset > twice rather than once. Sure, that doesn't take many extra cycles, > but if the point of all this is to micro-optimize this code, that > particular change is going in the wrong direction. I thought that is a good idea, considering the additional overhead is little, because that would be useful for some use-cases. But I think we need more discussions about that, so if there are no objections from Alvaro (or anyone), I'll leave that part as-is. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: