Re: Preserve attstattarget on REINDEX CONCURRENTLY - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Preserve attstattarget on REINDEX CONCURRENTLY
Date
Msg-id d4df50ad-fcb0-bc25-d0a4-71e0165b8511@enterprisedb.com
Whole thread Raw
In response to Preserve attstattarget on REINDEX CONCURRENTLY  (Ronan Dunklau <ronan@dunklau.fr>)
Responses Re: Preserve attstattarget on REINDEX CONCURRENTLY
List pgsql-hackers
On 2/4/21 11:04 AM, Ronan Dunklau wrote:
> Hello !
> 
> ...
> 
> junk=# REINDEX INDEX CONCURRENTLY t1_date_trunc_idx;
> REINDEX
> junk=# \d+ t1_date_trunc_idx 
>                                     Index "public.t1_date_trunc_idx"
>    Column   |            Type             | Key? |         Definition          
> | Storage | Stats target 
> ------------+-----------------------------+------
> +-----------------------------+---------+--------------
>  date_trunc | timestamp without time zone | yes  | date_trunc('day'::text, ts) 
> | plain   | 
> btree, for table "public.t1"
> 
> 
> I'm attaching a patch possibly solving the problem, but maybe the proposed 
> changes will be too intrusive ?
> 

Hmmm, that sure seems like a bug, or at least unexpected behavior (that
I don't see mentioned in the docs).

But the patch seems borked in some way:

$ patch -p1 < ~/keep_attstattargets_on_reindex_concurrently.patch
patch: **** Only garbage was found in the patch input.

There seem to be strange escape characters and so on, how did you create
the patch? Maybe some syntax coloring, or something?

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Is MaxHeapAttributeNumber a reasonable restriction for foreign-tables?
Next
From: Ronan Dunklau
Date:
Subject: Re: Preserve attstattarget on REINDEX CONCURRENTLY