From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: planner support functions: handle GROUP BY estimates ? |
Date: | 2020-01-14 21:21:57 |
Message-ID: | 32153.1579036917@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> On Tue, Jan 14, 2020 at 03:12:21PM -0500, Tom Lane wrote:
>> cc'ing Tomas in case he has any thoughts about it.
> Well, I certainly do thoughts about this - it's pretty much exactly what
> I proposed yesterday in this thread:
> https://www.postgresql.org/message-id/flat/20200113230008(dot)g67iyk4cs3xbnjju(at)development
> The third part of that patch series is exactly about supporting extended
> statistics on expressions, about the way you described here. The current
> status of the WIP patch is that grammar + ANALYZE mostly works, but
> there is no support in the planner. It's obviously still very hackish.
Cool. We should probably take the discussion to that thread, then.
> I'm also wondering if we could/should 100% rely on extended statistics,
> because those are really meant to track correlations between columns,
Yeah, it seems likely to me that the infrastructure for this would be
somewhat different --- the user-facing syntax could be basically the
same, but ultimately we want to generate entries in pg_statistic not
pg_statistic_ext_data. Or at least entries that look the same as what
you could find in pg_statistic.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-01-14 21:25:00 | Re: Unicode escapes with any backend encoding |
Previous Message | Andrew Dunstan | 2020-01-14 21:17:58 | Re: Unicode escapes with any backend encoding |