From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(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-19 08:31:45 |
Message-ID: | CA+HiwqF-PLA2TUF5mf9p_8C4X53X1NBNPVA_0LXKiwNRzM8r8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 18, 2022 at 11:53 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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.
Yes, agreed.
--
Amit Langote
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-01-19 08:32:36 | Re: SQL:2011 application time |
Previous Message | Amit Langote | 2022-01-19 08:30:59 | Re: generic plans and "initial" pruning |