From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mat Arye <mat(at)timescale(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Additional Statistics Hooks |
Date: | 2018-03-12 22:44:32 |
Message-ID: | 2822.1520894672@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mat Arye <mat(at)timescale(dot)com> writes:
> So the use-case is an analytical query like
> SELECT date_trunc('hour', time) AS MetricMinuteTs, AVG(value) as avg
> FROM hyper
> WHERE time >= '2001-01-04T00:00:00' AND time <= '2001-01-05T01:00:00'
> GROUP BY MetricMinuteTs
> ORDER BY MetricMinuteTs DESC;
> Right now this query will choose a much-less-efficient GroupAggregate plan
> instead of a HashAggregate. It will choose this because it thinks the
> number of groups
> produced here is 9,000,000 because that's the number of distinct time
> values there are.
> But, because date_trunc "buckets" the values there will be about 24 groups
> (1 for each hour).
While it would certainly be nice to have better behavior for that,
"add a hook so users who can write C can fix it by hand" doesn't seem
like a great solution. On top of the sheer difficulty of writing a
hook function, you'd have the problem that no pre-written hook could
know about all available functions. I think somehow we'd need a way
to add per-function knowledge, perhaps roughly like the protransform
feature.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-03-12 22:50:40 | Re: unique indexes on partitioned tables |
Previous Message | Andres Freund | 2018-03-12 22:28:07 | Re: explain with costs in subselect.sql |