| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
| Subject: | Re: Add important info about ANALYZE after create Functional Index |
| Date: | 2020-10-29 01:59:52 |
| Message-ID: | 20201029015952.GB2671@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 29, 2020 at 12:02:11AM +0100, Tomas Vondra wrote:
> On Wed, Oct 28, 2020 at 05:43:08PM -0300, Fabrízio de Royes Mello wrote:
>> 2) REINDEX CONCURRENTLY does not keep statistics (pg_statistc) like a
>> regular REINDEX for indexes using expressions and to me it's a bug. Michael
>> pointed out upthread that maybe we should rework a bit
>> index_concurrently_swap() to copy statistics from old index to new one.
>
> Yeah. Not sure it counts as a bug, but I see what you mean - it's
> definitely an unexpected/undesirable difference in behavior between
> plain REINDEX and concurrent one.
REINDEX CONCURRENTLY is by design wanted to provide an experience
transparent to the user similar to what a plain REINDEX would do, at
least that's the idea behind it, so.. This qualifies as a bug to me,
in spirit.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | tsunakawa.takay@fujitsu.com | 2020-10-29 02:08:02 | RE: [Patch] Optimize dropping of relation buffers using dlist |
| Previous Message | Tatsuro Yamada | 2020-10-29 01:34:44 | Re: list of extended statistics on psql |