From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER INDEX .. SET STATISTICS ... behaviour |
Date: | 2017-05-31 16:18:16 |
Message-ID: | CAPpHfdu7ULFatYQFZYfBNa+JkO3Ag__cVCYmnBtdY+XR7ih1tg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, May 31, 2017 at 6:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> > I've discovered that PostgreSQL is able to run following kind of queries
> in
> > order to change statistic-gathering target for an indexed expression.
>
> > ALTER INDEX index_name ALTER COLUMN expr SET STATISTICS stat_target;
>
> > It's been previously discussed in [1].
>
> > I think this should be fixed not just in docs. This is why I've started
> > thread in pgsql-hackers. For me usage of internal column names "expr",
> > "expr1", "expr2" etc. looks weird. And I think we should replace it
> with a
> > better syntax. What do you think about these options?
>
> > ALTER INDEX index_name ALTER EXPRESSION 0 SET STATISTICS stat_target; --
> > Refer expression by its number
> > ALTER INDEX index_name ALTER EXPRESSION (x + y) SET STATISTICS
> stat_target;
> > -- Refer expression by its definition
>
> Don't like either of those particularly, but what about just targeting
> a column by column number, independently of whether it's an expression?
>
> ALTER INDEX myindex ALTER COLUMN 4 SET STATISTICS 1000;
>
I completely agree with that.
If no objections, I will write a patch for that.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2017-05-31 16:22:18 | Re: [GENERAL] pg_basebackup error: replication slot "pg_basebackup_2194" already exists |
Previous Message | Alvaro Herrera | 2017-05-31 16:07:59 | Re: TAP backpatching policy |