Hi Patrick,
I believe Vacuum full rebuilds the indexes automatically by default, as a
new copy of the table is created.
Because the indexes are new, no stats are available to the optimiser to
make an informed decision about whether to utilise it or not, so it doesn't.
Once the analyze is perform
On Thu, Sep 1, 2016 at 10:32 AM, Patrick B wrote:
>
>
> 2016-09-01 11:53 GMT+12:00 Venkata B Nagothi :
>
>>
>> On Thu, Sep 1, 2016 at 8:41 AM, Patrick B
>> wrote:
>>
>>> Hi guys,
>>>
>>> A dev has ran a VACUUM FULL command into our test database running
>>> PostgreSQL 9.5 (I know... goddamn)
2016-09-01 11:53 GMT+12:00 Venkata B Nagothi :
>
> On Thu, Sep 1, 2016 at 8:41 AM, Patrick B
> wrote:
>
>> Hi guys,
>>
>> A dev has ran a VACUUM FULL command into our test database running
>> PostgreSQL 9.5 (I know... goddamn)...
>>
>> ... after the Vacuum Full, some queries start using SEQ s
On Thu, Sep 1, 2016 at 8:41 AM, Patrick B wrote:
> Hi guys,
>
> A dev has ran a VACUUM FULL command into our test database running
> PostgreSQL 9.5 (I know... goddamn)...
>
> ... after the Vacuum Full, some queries start using SEQ scans instead of
> indexes...
>
> Does that happen because of
Yes that very well could happen because the size of the table changed, as
well as stats being more accurate now. Just because you have a seq scan
doesn't mean the planer is making a bad choice.
Hi guys,
A dev has ran a VACUUM FULL command into our test database running
PostgreSQL 9.5 (I know... goddamn)...
... after the Vacuum Full, some queries start using SEQ scans instead of
indexes...
Does that happen because of the size of the table? The table that I'm
referring to is 150MB bi
