selecting from cursor
От | Alex Pilosov |
---|---|
Тема | selecting from cursor |
Дата | |
Msg-id | Pine.BSO.4.10.10106301524370.7004-100000@spider.pilosoft.com обсуждение исходный текст |
Ответы |
Re: selecting from cursor
|
Список | pgsql-hackers |
I hope I'm not taking too much time from people here... Here's where I'm now (and don't beat me too hard :) I'm done with change of RangeTblEntry into three different node types: RangeTblEntryRelation,RangeTblEntrySubSelect,RangeTblEntryPortal which have different fields. All the existing places instead of using rte->subquery to determine type now use IsA(rte, RangeTblEntrySubSelect), and later access fields after casting ((RangeTblEntrySubSelect *)rte)->xxx Some functions that always work on Relation RTEs are declared to accept RangeTblEntryRelation. Asserts are added everywhere before casting of RTE into specific type. (Unless there was an IsA before, then I didn't put an Assert). Let me know if that is an acceptable way of doing things, or casting makes things too ugly. (I believe its the best way, unions are more dangerous in this context). Let me know if it would make sense to rename these types into RTERelation,RTESubSelect,RTEPortal to cut down on their length ... Now, I'm going to more interesting stuff, planner: SELECT blah FROM CURSOR FOO, list_of_tables This really should place CURSOR FOO at the very top of join list, since (generally), you don't know what cursor is opened for, and you cannot ReScan a portal. I'm still trying to find out how to explain that to optimizer, but if someone gives me a hint, I'd appreciate it. Alternatively, we can store everything we retrieved from portal for future ReScan purposes, but I really don't like this idea. By the same token, I think, optimizer must reject queries of type: "SELECT ... FROM CURSOR FOO, CURSOR BAR" because such thing will lead to a nested loop scan, which is impossible because, again, you can't ReScan a cursor. Let me know if I'm very off track with these assumptions, and if you have to throw rocks at me, pick little ones ;) -alex
В списке pgsql-hackers по дате отправления: