Re: [HACKERS] cost_sort() may need to be updated

2016-09-13 Thread Peter Geoghegan
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

Re: [HACKERS] cost_sort() may need to be updated

2016-09-13 Thread Robert Haas
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

Re: [HACKERS] cost_sort() may need to be updated

2016-09-11 Thread Peter Geoghegan
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,

Re: [HACKERS] cost_sort() may need to be updated

2016-09-11 Thread Tom Lane
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

[HACKERS] cost_sort() may need to be updated

2016-09-09 Thread Peter Geoghegan
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 *