Re: support for MERGE

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: support for MERGE
Дата
Msg-id 3f45ed11-8b55-70f0-0c01-ff863313d0d1@enterprisedb.com
обсуждение исходный текст
Ответ на Re: support for MERGE  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: support for MERGE  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On 11/12/21 18:57, Alvaro Herrera wrote:
> Here's a new version.  Many of the old complaints have been fixed;
> particularly, the handling of partitioned tables is now much cleaner and
> straightforward.  Amit Langote helped considerably in getting this part
> to shape -- thanks for that.  Amit also helped correct the EvalPlanQual
> behavior, which wasn't quite up to snuff.
>

Thanks!

> There are a few things that can still be improved here.  For one, I need
> to clean up the interactions with table AM (and thus heapam.c etc).
> Secondarily, and I'm now not sure that I really want to do it, is change
> the representation for executor: instead of creating a fake join between
> target and source, perhaps we should have just source, and give
> optimizer a separate query to fetch tuples from target.
> 

When you say you're not sure you want to change this, is that because 
you don't have time for that, or because you think the current approach 
is better?

> What I did do is change how the target table is represented from parse
> analysis to executor.  For example, in the original code, there were two
> RTEs that represented the target table; that is gone.  Now the target
> table is always just the query's resultRelation.  This removes a good
> number of ugly hacks that had been objected to.
> 
> I'll park this in the January commitfest now.
> 


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: support for MERGE
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: XTS cipher mode for cluster file encryption