Jeff Davis <[EMAIL PROTECTED]> writes:
> On Thu, 2008-08-28 at 00:42 -0400, Tom Lane wrote:
>> The reason that these statements are not inconsistent is that the
>> Sort is the inner relation for a mergejoin. In the presence of
>> duplicate keys in the outer relation, a mergejoin will "rewind" and
On Thu, 2008-08-28 at 00:42 -0400, Tom Lane wrote:
> The reason that these statements are not inconsistent is that the
> Sort is the inner relation for a mergejoin. In the presence of
> duplicate keys in the outer relation, a mergejoin will "rewind" and
> rescan duplicate keys in the inner relatio
Jeff Davis <[EMAIL PROTECTED]> writes:
> This is in version 8.3.1 (I also tried 8.3.3).
> It looks like the sort is producing more rows than the input. The hash
> aggregate produces 10k, but the sort produces 10M.
> Merge Join (cost=199211.12..660979.37 rows=9998773 width=12) (actual
> time=8887
This is in version 8.3.1 (I also tried 8.3.3).
It looks like the sort is producing more rows than the input. The hash
aggregate produces 10k, but the sort produces 10M.
Am I just misinterpreting this output? Even the optimizer thinks that
the output of the hashagg and the output of the sort shoul
