From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: no MCV list of tiny table with unique columns |
Date: | 2016-11-05 22:36:37 |
Message-ID: | 20161105223637.GJ2139@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Brusselback | 2016-11-07 15:52:12 | Query much slower after upgrade to 9.6.1 |
Previous Message | Claudio Freire | 2016-11-04 22:30:32 | Re: archive_command too slow. |