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 be useful here.
>
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
>
> 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
assurance that it won't have to hit the heap heavily anyway. Try doing a
SE
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
Can anyone enlighten me on exactly what triggers an "aggressive"
vacuum? I have read the docs multiple times (and watched several
videos!), but the changes I make do not have the expected outcomes; so
I'm clearly missing something.
https://www.postgresql.org/docs/15/routine-vacuuming.html#VACUUM-F
