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

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, David Rowley <dgrowley(at)gmail(dot)com>
Subject: Re: BUG #15383: Join Filter cost estimation problem in 10.5
Date: 2020-12-01 15:23:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs pgsql-hackers

On 30.10.2020 19:33, David G. Johnston wrote:
> On Fri, Oct 30, 2020 at 9:16 AM Anastasia Lubennikova
> <lubennikovaav(at)gmail(dot)com <mailto:lubennikovaav(at)gmail(dot)com>> wrote:
> Status update for a commitfest entry.
> It looks like there was no real progress on this issue since
> April. I see only an experimental patch. What kind of review does
> it need right now? Do we need more testing or maybe production
> statistics for such queries?
> David, are you going to continue working on it?
> Can you, please, provide a short summary of the problem and list
> open questions for reviewers.
> The new status of this patch is: Waiting on Author
> I agree that updating a wiki seems like an unappealing conclusion to
> this entry.  I'm on the fence whether we just leave it in the cf and
> get a periodic nag when it gets bumped.  As we are describing real
> problems or potential improvements to live portions of the codebase
> ISTM that adding code comments near to those locations would be
> warranted.  The commit message can reference this thread.  There seems
> to already be a convention for annotating code comments in such a way
> that they can be searched for - which basically is what sticking it in
> the wiki would accomplish but the searcher would have to look in the
> codebase and not on a website.  For the target audience of this
> specific patch that seems quite reasonable.
> David J.
Here we are again.
The commitfest is closed now and the discussion haven't moved from where
it was a month ago.
I don't see any use in moving it to the next CF as is and I don't want
to return it either, as this is clearly a bug.

I think we have a few options:

1. We can add it into TODO until better times.
2. We can write a patch to address this problem in code comments.
3. We can maybe CC this thread to someone and ask for help. Do you know
people, who have  expertise in this area?

None of these options is perfect, but the second option will perhaps be
a good compromise.
David, can you, please submit a patch?

Anastasia Lubennikova
Postgres Professional:
The Russian Postgres Company

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-12-01 15:24:51 Re: BUG #16755: A specification or a bug? Digit drop on CAST from DOUBLE PRECISION to NUMERIC.
Previous Message Dave Page 2020-12-01 14:27:12 Re: [External] Re: pgadmin--pgagent---the process hang by unknow reasons

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-12-01 15:25:19 Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Previous Message Krunal Bauskar 2020-12-01 15:19:06 Re: Improving spin-lock implementation on ARM.