Re: Add important info about ANALYZE after create Functional Index

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Fabrízio Mello <fabriziomello(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add important info about ANALYZE after create Functional Index
Date: 2020-10-28 19:12:01
Message-ID: 20201028191201.wh5ldvhsiqy2vknu@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Oct 28, 2020 at 12:00:54PM -0700, David G. Johnston wrote:
>On Wed, Oct 28, 2020 at 11:55 AM Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
>> I agree the lack of stats may be quite annoying and cause issues, but my
>> guess is the chances of backpatching such change are about 0.000001%. We
>> have a usable 'workaround' for this - manual analyze.
>My guess is that it wouldn't be too difficult to write a patch that could
>be safely back-patched and it's worth doing so even if ultimately the
>decision is not to. But then again the patch writer isn't going to be me.
>Given how simple the manual workaround is not having it be manual seems
>like it would be safe and straight-forward to implement.

Maybe, but I wouldn't be surprised if it was actually a bit trickier in
practice, particularly for the CONCURRENTLY case. But I haven't tried.

Anyway, I think there's an agreement it'd be valuable to do this after
CREATE INDEX in the future, so if someone wants to implement it that'd
be great. We can consider backpatching only once we have an actual patch


Tomas Vondra
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-10-28 19:12:19 Re: Internal key management system
Previous Message Heikki Linnakangas 2020-10-28 19:10:41 Deduplicate aggregates and transition functions in planner