On Fri, Nov 12, 2021 at 9:58 AM Alvaro Herrera <alvhe...@alvh.no-ip.org> 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. > > 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. > > 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. > > -- > Álvaro Herrera Valdivia, Chile — > https://www.EnterpriseDB.com/ > "Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; > jugar > al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en > La Feria de las Tinieblas, R. Bradbury) > Hi, + skipped_path = total - insert_path - update_path - delete_path; Should there be an assertion that skipped_path is not negative ? + * We maintain separate transaction tables for UPDATE/INSERT/DELETE since + * MERGE can run all three actions in a single statement. Note that UPDATE + * needs both old and new transition tables Should the 'transaction' in the first line be transition ? cheers
