Hi all,
I'm trying to come up with an efficient query, ideally without having
to coerce the planner into doing what I want, but I'm running up
against a problem with row estimates, and I'm curious if there's a
better way to address the problem than what I've come up with.
Here's a straightforward
On Tue, Jul 30, 2024 at 11:34 AM Andrei Lepikhov wrote:
>
> Thanks for report. I see such cases frequently enough and the key
> problem here is data skew, as you already mentioned. Extended statistics
> doesn't help here. Also, because we can't estimate specific values
> coming from the outer Nest
I'm trying to speed up a particular query, so I tried out a very
specific index meant to target this one query alone. (I'm not at all
convinced that's a good idea, but I'm curious to see just how fast I
can make this one query.) The index is like this:
create index idx_foo on my_tbl (start_on) whe
On Thu, Dec 19, 2024 at 2:09 PM Jon Zeppieri wrote:
>
> The row estimate is not good. The query estimates 317919 rows but
> there are only 27701. There is some correlation here; if end_on is
> null, start_on is a lot more likely to be recent, so maybe extended
> statistics would
On Thu, Dec 19, 2024 at 1:39 PM Greg Sabino Mullane wrote:
>>
>> Why wouldn't it do an index (or, really, an index only) scan in this case
>
>
> Well, it did do an index scan (and a bitmap scan is a pretty good solution
> here), but as to why no indexonly scan, there is probably not enough
> ass
On Fri, Dec 20, 2024 at 4:57 AM Frédéric Yhuel
wrote:
>
>
>
> On 12/20/24 09:16, Frédéric Yhuel wrote:
> >
> >
> > On 12/19/24 20:09, Jon Zeppieri wrote:
> >> The table is freshly vacuumed. If I disable bitmap scans, it will do
> >> an index only
