Re: Upgrading pg_statistic to handle collation honestly

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Upgrading pg_statistic to handle collation honestly
Date: 2018-12-13 07:20:47
Message-ID: 6e3eddc2-5084-e0c9-43bc-39649efd5331@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/12/2018 16:57, Tom Lane wrote:
> Attached is a draft patch for same. It adds storage to pg_statistic
> to record the collation of each statistics "slot". A plausible
> alternative design would be to just say "look at the collation of the
> underlying column", but that would require extra catcache lookups in
> the selectivity functions that need the info.

That looks like a good approach to me.

> Doing it like this also
> makes it theoretically feasible to track stats computed with respect
> to different collations for the same column, though I'm not really
> convinced that we'd ever do that.

It's a good option to keep around. Maybe someday extended statistics
could be used to ask for additional statistics to be collected.

> * Probably this conflicts to some extent with Peter's "Reorganize
> collation lookup" patch, but I haven't studied that yet.

I've looked it over, and it's nothing that can't be easily fixed up. In
fact, it simplifies a few things, so I'm in favor of moving your patch
along first.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2018-12-13 09:23:12 Row Visibility and Table Access Methods
Previous Message Surafel Temesgen 2018-12-13 07:09:20 Re: COPY FROM WHEN condition