From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Odd number of rows expected |
Date: | 2005-01-23 22:39:12 |
Message-ID: | 7191.1106519952@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Jim C. Nasby" <decibel(at)decibel(dot)org> writes:
> In english, each bucket defines a specific time period, and no two
> buckets can over-lap (though there's no constraints defined to actually
> prevent that). So reality is that each row in page_log.log will in fact
> only match one row in bucket (at least for each value of rrs_id).
> Given that, would the optimizer make a better choice if it knew that
> (since it means a much smaller result set).
Given that the join condition is not an equality, there's no hope of
using hash or merge join; so the join itself is about as good as you're
gonna get. With a more accurate rows estimate for the join result, it
might have decided to use HashAggregate instead of Sort/GroupAggregate,
but AFAICS that would not have made a huge difference ... at best maybe
25% of the total query time.
> Is there any way to tell the
> optimizer this is the case?
Nope. This gets back to the old problem of not having any cross-column
(cross-table in this case) statistics.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2005-01-23 22:42:52 | Re: PostgreSQL clustering VS MySQL clustering |
Previous Message | Jim C. Nasby | 2005-01-23 22:29:42 | Re: Odd number of rows expected |