Re: Common Table Expressions applied; some issues remain

Поиск
Список
Период
Сортировка
От Hitoshi Harada
Тема Re: Common Table Expressions applied; some issues remain
Дата
Msg-id e08cc0400905262029x2e08051fvc622500939a95255@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Common Table Expressions applied; some issues remain  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Common Table Expressions applied; some issues remain  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
2009/5/27 Tom Lane <tgl@sss.pgh.pa.us>:
> Greg Stark <stark@enterprisedb.com> writes:
>> [ point 1 here remains unresolved:
>>   http://archives.postgresql.org/message-id/9623.1223158943@sss.pgh.pa.us ]
>
>> One possibility would be to not flatten the query but find these quals
>> and copy them onto the cte when planning the cte. So we would still
>> materialize the result and avoid duplicate execution but only fetch
>> the records which we know a caller will need. We could even do that
>> for multiple callers if we join their quals with an OR -- that still
>> might allow a bitmap index scan.
>
> I'm not too thrilled about that solution because it still eliminates
> predictability of execution of volatile functions.  It's really just a
> partial form of subquery pullup, so we're paying all the disadvantages
> for only a subset of the advantages.
>
> I could still see doing what I mentioned in the prior message, which is
> to flatten CTEs as if they are plain sub-selects when
>
> 1. they are non-recursive,
> 2. they are referenced only once, and
> 3. they contain no volatile functions.
>

And 4. only if the sub-selects use index scan? Or in other cases would
it be effective?

Regards,

--
Hitoshi Harada


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [pgsql-www] commitfest management webapp
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Common Table Expressions applied; some issues remain