On Tue, Sep 13, 2016 at 5:59 AM, Robert Haas wrote:
> I think that the only real way to judge whether cost_sort() is any
> good is to see whether it causes the wrong plan to be chosen in some
> cases. For example, it could cause merge joins to be picked too
> frequently or too infrequently, or it
On Sun, Sep 11, 2016 at 12:13 PM, Peter Geoghegan wrote:
> On Sun, Sep 11, 2016 at 9:01 AM, Tom Lane wrote:
>> Peter Geoghegan writes:
>>> I think that we *can* refine this guess, and should, because random
>>> I/O is really quite unlikely to be a large cost these days (I/O in
>>> general often
On Sun, Sep 11, 2016 at 9:01 AM, Tom Lane wrote:
> Peter Geoghegan writes:
>> I think that we *can* refine this guess, and should, because random
>> I/O is really quite unlikely to be a large cost these days (I/O in
>> general often isn't a large cost, actually). More fundamentally, I
>> think it
Peter Geoghegan writes:
> I think that we *can* refine this guess, and should, because random
> I/O is really quite unlikely to be a large cost these days (I/O in
> general often isn't a large cost, actually). More fundamentally, I
> think it's a problem that cost_sort() thinks that external sorts
