From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: generic plans and "initial" pruning |
Date: | 2022-01-18 14:53:05 |
Message-ID: | CA+TgmoYOjmn2DYiWTAYSWiE-QN=qa6WYfk1CdEKLGUGSpBNcsA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 18, 2022 at 3:10 AM Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> Pursuing that kind of a project would perhaps have been more
> worthwhile if the locking issue had affected more than just this
> particular case, that is, the case of running prepared statements over
> partitioned tables using generic plans. Addressing this by
> rearchitecting run-time pruning (and plancache to some degree) seemed
> like it might lead to this getting fixed in a bounded timeframe. I
> admit that the concerns that Robert has raised about the patch make me
> want to reconsider that position, though maybe it's too soon to
> conclude.
I wasn't trying to say that your approach was dead in the water. It
does create a situation that can't happen today, and such things are
scary and need careful thought. But redesigning the locking mechanism
would need careful thought, too ... maybe even more of it than sorting
this out.
I do also agree with Simon that this is an important problem to which
we need to find some solution.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2022-01-18 14:56:30 | Re: Pluggable toaster |
Previous Message | James Coleman | 2022-01-18 14:47:44 | Re: Add last commit LSN to pg_last_committed_xact() |