| 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: | Whole Thread | Raw Message | 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
| 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 |