Re: Unnecessary locks for partitioned tables

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: n(dot)kobzarev(at)aeronavigator(dot)ru
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Unnecessary locks for partitioned tables
Date: 2022-11-09 18:29:52
Message-ID: CAApHDvo89+WTF+GiWsswRwggSqMNJwpDGwKm2dgpavCRADGH8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 10 Nov 2022 at 04:11, <n(dot)kobzarev(at)aeronavigator(dot)ru> wrote:
> If someone would create delayed locking for generic plans, after parameters
> are known and partition pruning occurs, I believe generic plan will be on
> pars with custom.
> So, I`m sticking with plan cache parameter for feature development, that was
> clear.

The current problem is that the locks must be obtained on the objects
mentioned in the plan so that we can check if anying has been modified
that might invalidate the prepared plan. For example, index has been
dropped, partition dropped, etc. The partition pruning in your
prepared plan is currently done during executor startup, which is
after the locks are obtained (which is why we must lock everything in
the plan).

There is a patch around at the moment that moves the run-time
partition pruning away from executor startup to before we obtain the
locks so that we can forego the locking of partitions which have been
pruned. If that patch makes it then the problem will be solved, at
least starting with the version the patch makes it into.

David

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bryn Llewellyn 2022-11-09 18:55:35 Re: "set role" semantics
Previous Message Peter J. Holzer 2022-11-09 16:17:59 Re: copy file from a client app to remote postgres isntance