On Wed, Nov 02, 2016 at 07:48:23PM -0400, Tom Lane wrote:
> There's not a lot of point in worrying about your two-row table when these
> other estimates are off by multiple orders of magnitude. In this
> particular case my first bet would be that the planner has no idea about
> the selectivity of the conditions on "echo_tango('seven_november'::text,
> four_charlie)". Reformulating that, or maybe making an index on it just
> so that ANALYZE will gather stats about it, could help.
Thanks, you're exactly right. That's date_trunc('hour') BTW.
We actually already have a "new way" of doing that which avoids date_trunc, so
now I just have to get it in place for 100+ old reports..
I thought I had tried that before, but I think I was confusing myself, and
tried putting the index on the parent, which ends up with no stats since it's
empty.
With indices+analyze:
Sort (cost=189014.28..189014.28 rows=1 width=785) (actual
time=25063.831..25063.886 rows=328 loops=1)
...
BTW:
join_collapse_limit | 8
from_collapse_limit | 8
..and changing them doesn't seem to have any effect. By my count there's 11
tables, not counting multiply a few used multiply..
Thanks again.
Justin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
