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 |
Thread: | |
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>
>wrote:
>
>> 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
anyway.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 |