Re: ModifyTable overheads in generic plans - Mailing list pgsql-hackers

From David Rowley
Subject Re: ModifyTable overheads in generic plans
Date
Msg-id CAApHDvqADVMKbKQE8peDy1+c4tFtAE=nCFous5wMZA4g=ESQVg@mail.gmail.com
Whole thread Raw
In response to Re: ModifyTable overheads in generic plans  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: ModifyTable overheads in generic plans  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
On Thu, 8 Apr 2021 at 15:32, Amit Langote <amitlangote09@gmail.com> wrote:
> There's 10-20% improvement in this case too for various partition
> counts, which really has more to do with 86dc90056 than the work done
> here.

I'm not sure of the exact query you're running, but I imagine the
reason that it wasn't that slow with custom plans was down to
428b260f87.

So the remaining slowness for the generic plan case with large numbers
of partitions in the plan vs custom plans plan-time pruning is a)
locking run-time pruned partitions; and; b) permission checks during
executor startup?

Aside from the WCO and RETURNING stuff you mentioned, I mean.

David



pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: TRUNCATE on foreign table
Next
From: Tom Lane
Date:
Subject: Re: SQL-standard function body