Re: How to share the result data of separated plan

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема Re: How to share the result data of separated plan
Дата
Msg-id 4CD6F162.8070302@cs.helsinki.fi
обсуждение исходный текст
Ответ на Re: How to share the result data of separated plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2010-11-07 8:08 PM +0200, Tom Lane wrote:
> Marko Tiikkaja<marko.tiikkaja@cs.helsinki.fi>  writes:
>> On 2010-11-07 6:23 PM +0200, Tom Lane wrote:
>>> Um ... why?  I thought the whole point of breaking out ModifyTable
>>> as a separate node type was so that a query involving writeable CTEs
>>> would still be just one plan tree.
>
>> We tried that for 9.0 and it didn't work.  Almost all work for 9.1 has
>> been spent on creating an infrastructure for running the executor
>> separately for every WITH list element when wCTEs are present.
>
> I guess I shoulda been paying closer attention :-(.  That really, really
> seems like fundamentally the wrong direction.  What was it that was
> unfixable about the other way?  If it is unfixable, should we revert
> ModifyTable?

The immediate problem at hand was that scan nodes cached the number of 
blocks a relation has and didn't see new tuples added by wCTEs.  That's 
not unfixable, but the consensus seemed to be that running the executor 
separately is better.

ModifyTable nodes still save us from duplicating a lot of code; you can 
just run an executor on a plan and expect it to work, even it's a DML 
statement.  Reverting it would be a huge mistake in my opinion.


Regards,
Marko Tiikkaja


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: How to share the result data of separated plan
Следующее
От: Gurjeet Singh
Дата:
Сообщение: Re: Patch to add a primary key using an existing index