Re: Custom opclass for column statistics?

From: Ancoron Luciferis <ancoron(dot)luciferis(at)googlemail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: Custom opclass for column statistics?
Date: 2019-07-09 22:16:38
Message-ID: ac9a8640-c421-7662-5e0c-05648c926176@googlemail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 06/07/2019 15:58, Tom Lane wrote:
> Ancoron Luciferis <ancoron(dot)luciferis(at)googlemail(dot)com> writes:
>> I've been wondering whether it is possible somehow to have the standard
>> column statistics to respect a certain operator class?
>
> In principle, pg_statistic can represent stats for a non-default opclass.
> Teaching ANALYZE to collect such stats when appropriate, and then teaching
> the planner to use them when appropriate, is left as an exercise for the
> reader.

Hehe, now that you are saying it, I realize what I was actually asking
for with this... ;)

>
> I think the "when appropriate" bit is actually the hardest part of that.
> Possibly, if you were satisfied with a relatively manual approach,
> you could proceed by using CREATE STATISTICS to declare interest in
> keeping standard stats for a non-default sort order. Not sure what to
> do if you want it to be automatic, because I don't think people would
> hold still for having ANALYZE collect stats for any random non-default
> opclass automatically. Maybe a new opclass property?

I totally agree with the complications around all that.

Now I think if I want better statistics and better plans for my new
time-sorted index, I will need a new data type for which I can set the
opclass as default, which also would provide users the guarantee that
they'll get what they expect.

Thanx and cheers,

Ancoron

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Omar Roth 2019-07-11 22:22:03 Re: Optimizing `WHERE x IN` query
Previous Message Ancoron Luciferis 2019-07-09 22:08:34 Re: UUID v1 optimizations...