Re: BUG #15383: Join Filter cost estimation problem in 10.5

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15383: Join Filter cost estimation problem in 10.5
Date: 2020-09-25 01:49:15
Message-ID: CAApHDvrGnJpE=eHPvSPGd1mmxGKUenyCFHbzG9c0cyqAeq_3SA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Thu, 24 Sep 2020 at 18:33, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Sep 24, 2020 at 05:10:26PM +1200, David Rowley wrote:
> > ... putting it in a place we might one day look again might be better :-)
>
> So am I getting correctly that you are suggesting to wipe out entirely
> the existing TODO list and recreate a new one? That works for me :p

What I meant was, I never look at the TODO list on the wiki. I don't
think it's a good place to put it if we want to maintain the
motivation to get the problem fixed.

> Except for that, I don't have a better idea than creating a new page
> on the wiki, like something named after planner improvements, if we
> don't want to keep this stuff in the CF for now.

It seems a bit backwards to me to move a reminder for an item that we
want to fix to somewhere less visible. Feels a bit like sweeping bugs
under the carpet. That does not make them go away.

Rather than see the item moved off somewhere else, my personal view is
that if people don't like the item being there then the likely best
course of action is for them to have a look at the problem and/or the
patch and voice their opinion on it and try to get the discussion
going again. If the discussion concludes with that the problem is not
big enough to warrant fixing it then we can leave a note and withdraw
the item.

However, to me it feels like a good time to make these sort of changes
in the planner. There's still plenty of time for people to complain if
they don't like what we've done before PG14 ships.

David

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Xinyu Liu 2020-09-25 02:43:55 Re: BUG #16624: Query Optimizer - Performance bug related to predicate simplification
Previous Message Fujii Masao 2020-09-25 00:46:58 Re: PG13 pg_receivewal failing

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2020-09-25 01:51:22 Re: Logical replication from PG v13 and below to PG v14 (devel version) is not working.
Previous Message Michael Paquier 2020-09-25 01:27:39 Re: Memory allocation abstraction in pgcrypto