On Tue, Apr 7, 2020 at 8:52 PM David Rowley wrote:
> On Wed, 25 Mar 2020 at 15:37, Amit Langote wrote:
> > Actually, I was saying in that email that the update/delete planning
> > overhaul being talked about will make the entirety of the
> > functionality this patch is adding, which is ModifyTabl
On Wed, 25 Mar 2020 at 15:37, Amit Langote wrote:
> Actually, I was saying in that email that the update/delete planning
> overhaul being talked about will make the entirety of the
> functionality this patch is adding, which is ModifyTable node being
> able to prune its subplans based on run-time
Hi David,
Sorry I couldn't get to this sooner.
On Wed, Mar 25, 2020 at 9:49 AM David Rowley wrote:
> On Wed, 25 Mar 2020 at 13:00, Tom Lane wrote:
> > David Rowley writes:
> > > I had a closer look at this today and the code I have in
> > > inheritance_planner() is certainly not right.
> >
> >
On Wed, 25 Mar 2020 at 13:00, Tom Lane wrote:
>
> David Rowley writes:
> > I had a closer look at this today and the code I have in
> > inheritance_planner() is certainly not right.
>
> Although I didn't get around to it for v13, there's still a plan on the
> table for inheritance_planner() to ge
David Rowley writes:
> I had a closer look at this today and the code I have in
> inheritance_planner() is certainly not right.
Although I didn't get around to it for v13, there's still a plan on the
table for inheritance_planner() to get nuked from orbit [1].
Maybe this improvement should be pu
On Tue, 10 Mar 2020 at 00:13, David Rowley wrote:
> Over in inheritance_planner(), I noticed that the RT index of the
> SELECT query and the UPDATE/DELETE query can differ. There was some
> code that performed translations. I changed that code slightly so that
> it's a bit more optimal. It was bu
Thanks for having a look at this, Amit.
On Fri, 24 Jan 2020 at 21:57, Amit Langote wrote:
>
> On Thu, Jan 23, 2020 at 4:31 PM Amit Langote wrote:
> Part of the optimizer patch that looks a bit complex is the changes to
> inheritance_planner() which is to be expected, because that function
> is a
On Thu, Jan 23, 2020 at 4:31 PM Amit Langote wrote:
> Now, the chances of such a big overhaul of how UPDATEs of inheritance
> trees are handled getting into PG 13 seem pretty thin even if I post
> the patch in few days, so perhaps it would make sense to get this
> patch in so that we can give user
Sorry, I didn't notice this email until now.
On Wed, Nov 27, 2019 at 5:17 PM Michael Paquier wrote:
> On Tue, Nov 05, 2019 at 04:04:25PM +1300, Thomas Munro wrote:
> > On Thu, Sep 12, 2019 at 10:10 AM Alvaro Herrera
> > wrote:
> > > Here's a rebased version of this patch (it had a trivial confli
On Thu, Jan 16, 2020 at 10:45:25PM +0100, Tomas Vondra wrote:
> David, this patch is marked as "waiting on author" since 11/27, and
> there have been no updates or responses since then. Do you plan to
> submit a new patch version in this CF? We're already half-way through,
> so there's not much tim
On Wed, Nov 27, 2019 at 05:17:06PM +0900, Michael Paquier wrote:
On Tue, Nov 05, 2019 at 04:04:25PM +1300, Thomas Munro wrote:
On Thu, Sep 12, 2019 at 10:10 AM Alvaro Herrera
wrote:
> Here's a rebased version of this patch (it had a trivial conflict).
Hi, FYI partition_prune.sql currently fail
On Tue, Nov 05, 2019 at 04:04:25PM +1300, Thomas Munro wrote:
> On Thu, Sep 12, 2019 at 10:10 AM Alvaro Herrera
> wrote:
> > Here's a rebased version of this patch (it had a trivial conflict).
>
> Hi, FYI partition_prune.sql currently fails (maybe something to do
> with commit d52eaa09?):
David,
On Thu, Sep 12, 2019 at 10:10 AM Alvaro Herrera
wrote:
> Here's a rebased version of this patch (it had a trivial conflict).
Hi, FYI partition_prune.sql currently fails (maybe something to do
with commit d52eaa09?):
where s.a = $1 and s.b = $2 and s.c = (select 1);
explain (costs off) execute
Here's a rebased version of this patch (it had a trivial conflict).
No further changes.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/post
gmail.com]
> Sent: Monday, July 8, 2019 11:34 AM
> To: Kato, Sho/加藤 翔
> Cc: David Rowley ; PostgreSQL Hackers
>
> Subject: Re: Run-time pruning for ModifyTable
>
> Kato-san,
>
> On Thu, Jul 4, 2019 at 1:40 PM Kato, Sho wrote:
> > > If I understand the details of [
Kato-san,
On Thu, Jul 4, 2019 at 1:40 PM Kato, Sho wrote:
> > If I understand the details of [1] correctly, ModifyTable will no longer
> > have N subplans for N result relations as there are today. So, it doesn't
> > make sense for ModifyTable to contain PartitionedRelPruneInfos and for
> > Exec
Langote [mailto:amitlangot...@gmail.com]
> Sent: Wednesday, July 3, 2019 5:41 PM
> To: David Rowley
> Cc: PostgreSQL Hackers
> Subject: Re: Run-time pruning for ModifyTable
>
> On Wed, Jul 3, 2019 at 4:34 PM David Rowley
> wrote:
> > On Wed, 3 Jul 2019 at 17:27, Ami
On Wed, Jul 3, 2019 at 4:34 PM David Rowley
wrote:
> On Wed, 3 Jul 2019 at 17:27, Amit Langote wrote:
> > A cursory look at the patch suggests that most of its changes will be
> > for nothing if [1] materializes. What do you think about that?
>
> Yeah, I had this in mind when writing the patch,
On Wed, 3 Jul 2019 at 17:27, Amit Langote wrote:
> A cursory look at the patch suggests that most of its changes will be
> for nothing if [1] materializes. What do you think about that?
Yeah, I had this in mind when writing the patch, but kept going
anyway. I think it's only really a small patc
Hi David,
On Thu, Jun 27, 2019 at 2:28 PM David Rowley
wrote:
> Deja vu from this time last year when despite everyone's best efforts
> (mostly Alvaro) we missed getting run-time pruning in for MergeAppend
> into the PG11 release. This year it was ModifyTable, which is now
> possible thanks to
20 matches
Mail list logo
