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
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 Amit and Tom's modifications to the inheritance
planner.
I've attached
21 matches
Mail list logo
