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
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
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,
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
For external sorts, cost_sort() assumes the following:
* The disk traffic is assumed to be 3/4ths sequential and 1/4th random
* accesses (XXX can't we refine that guess?)
...
/* Assume 3/4ths of accesses are sequential, 1/4th are not */
startup_cost += npageaccesses *