Re: Postgres Optimizer ignores information about foreign key relationship, severly misestimating number of returned rows in join

"Ehrenreich, Sigrid" writes: > A patch would be very much appreciated. > We are currently running on Version 12, but could upgrade to 13, if necessary. > Could you send me a notification if you managed to program a patch for that? I've pushed a patch for this to HEAD, but current thinking is that

query plan using partial index expects a much larger number of rows than is possible

Hello, I have a large table (about 13 million rows) full of customer order information. Since most of that information is for orders that have already been fulfilled, I have a partial index to help quickly zero in on rows that have not been fulfilled. This works well, but I noticed today when jo

Re: query plan using partial index expects a much larger number of rows than is possible

"Olivier Poquet" writes: > Looking at it in more detail, I found that the planner is assuming that I'll > get millions of rows back even when I do a simple query that does an index > scan on my partial index: We don't look at partial-index predicates when trying to estimate the selectivity of a

Re: query plan using partial index expects a much larger number of rows than is possible

Thanks Tom, That makes perfect sense. I'd already gone the route of materializing the condition but I didn't even realize that generated columns was an option (I'd done the same with triggers instead). So thanks a lot of that too! -- Olivier Poquet opoq...@plumdev.com On Wed, Oct 28, 2

Re: Understanding bad estimate (related to FKs?)

On Mon, Oct 26, 2020 at 11:20:01AM -0600, Michael Lewis wrote: > On Mon, Oct 26, 2020 at 11:14 AM Philip Semanchuk > wrote: > > > >> The item I'm focused on is node 23. The estimate is for 7 rows, actual > > is 896 (multiplied by 1062 loops). I'm confused about two things in this > > node. > > >