On Fri, Apr 3, 2015 at 1:49 PM, Robert Haas wrote:
> Committed. For future reference, I'd prefer to have things like this
> added to the next CF rather than no CF at all.
I'll bear that in mind. Thanks.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
On Mon, Feb 23, 2015 at 7:44 PM, Peter Geoghegan wrote:
> On Mon, Feb 23, 2015 at 4:41 PM, Tomas Vondra
> wrote:
>> Are you going to add this into the CF? Would be nice to get this into
>> 9.5. Strictly speaking it should go to 2015-06 I guess, but I'd consider
>> it part of one of the existing s
On Tue, Mar 3, 2015 at 2:00 AM, Jeremy Harris wrote:
> Yes; there seemed no advantage to any additional complexity.
> The merge consistently performs fewer comparisons than the
> quicksort, on random input - and many fewer if there are
> any sorted (or reverse-sorted) sections. However, it also
>
On 03/03/15 03:08, Arthur Silva wrote:
> Does it always perform mergesort instead of quicksort when enabled?
Yes; there seemed no advantage to any additional complexity.
The merge consistently performs fewer comparisons than the
quicksort, on random input - and many fewer if there are
any sorted (
On Mon, Mar 2, 2015 at 8:04 PM, Jeremy Harris wrote:
> On 25/02/15 00:32, Jeremy Harris wrote:
> > On 23/02/15 16:40, Tomas Vondra wrote:
> >> On 22.2.2015 22:30, Peter Geoghegan wrote:
> >>> You should try it with the data fully sorted like this, but with one
> >>> tiny difference: The very last
On 25/02/15 00:32, Jeremy Harris wrote:
> On 23/02/15 16:40, Tomas Vondra wrote:
>> On 22.2.2015 22:30, Peter Geoghegan wrote:
>>> You should try it with the data fully sorted like this, but with one
>>> tiny difference: The very last tuple is out of order. How does that
>>> look?
>
> If this ca
On 25/02/15 00:42, Peter Geoghegan wrote:
> On Tue, Feb 24, 2015 at 4:32 PM, Jeremy Harris wrote:
>> On 23/02/15 16:40, Tomas Vondra wrote:
>>> On 22.2.2015 22:30, Peter Geoghegan wrote:
You should try it with the data fully sorted like this, but with one
tiny difference: The very last t
On Tue, Feb 24, 2015 at 4:32 PM, Jeremy Harris wrote:
> On 23/02/15 16:40, Tomas Vondra wrote:
>> On 22.2.2015 22:30, Peter Geoghegan wrote:
>>> You should try it with the data fully sorted like this, but with one
>>> tiny difference: The very last tuple is out of order. How does that
>>> look?
>
On 23/02/15 16:40, Tomas Vondra wrote:
> On 22.2.2015 22:30, Peter Geoghegan wrote:
>> You should try it with the data fully sorted like this, but with one
>> tiny difference: The very last tuple is out of order. How does that
>> look?
If this case is actually important, a merge-sort can take
si
On 24.2.2015 01:44, Peter Geoghegan wrote:
> On Mon, Feb 23, 2015 at 4:41 PM, Tomas Vondra
> wrote:
>> Are you going to add this into the CF? Would be nice to get this into
>> 9.5. Strictly speaking it should go to 2015-06 I guess, but I'd consider
>> it part of one of the existing sortsupport pat
On Mon, Feb 23, 2015 at 4:41 PM, Tomas Vondra
wrote:
> Are you going to add this into the CF? Would be nice to get this into
> 9.5. Strictly speaking it should go to 2015-06 I guess, but I'd consider
> it part of one of the existing sortsupport patches.
It's a bugfix, IMV. I guess I should add it
On 23.2.2015 21:52, Peter Geoghegan wrote:
> On Mon, Feb 23, 2015 at 11:17 AM, Tomas Vondra
> wrote:
>> So while it's true that for the 3rd query we get much worse results
>> compared to the other queries (i.e. we don't get >400% speedup but ~3%
>> slowdown compared to master), it's true that mast
On Mon, Feb 23, 2015 at 11:17 AM, Tomas Vondra
wrote:
> So while it's true that for the 3rd query we get much worse results
> compared to the other queries (i.e. we don't get >400% speedup but ~3%
> slowdown compared to master), it's true that master performs
> exceptionally well for this query wi
On 23.2.2015 19:22, Peter Geoghegan wrote:
> On Mon, Feb 23, 2015 at 8:40 AM, Tomas Vondra
> wrote:
>> The durations are much higher than without the single unsorted row added
>> at the end. Queries often take 20x longer to finish (on the same code),
>> depending on the scale.
>
> I knew this wou
On Mon, Feb 23, 2015 at 8:40 AM, Tomas Vondra
wrote:
> The durations are much higher than without the single unsorted row added
> at the end. Queries often take 20x longer to finish (on the same code),
> depending on the scale.
I knew this would happen. :-)
> What's interesting here is that som
Hi,
On 22.2.2015 22:30, Peter Geoghegan wrote:
> On Sun, Feb 22, 2015 at 1:19 PM, Tomas Vondra
> wrote:
>> In short, this fixes all the cases except for the ASC sorted data. I
>> haven't done any code review, but I think we want this.
>>
>> I'll use data from the i5-2500k, but it applies to the X
On 23.2.2015 00:16, Peter Geoghegan wrote:
> On Sun, Feb 22, 2015 at 1:30 PM, Peter Geoghegan wrote:
>> You should try it with the data fully sorted like this, but with one
>> tiny difference: The very last tuple is out of order. How does that
>> look?
I'm running that test now, I'll post the res
On Sun, Feb 22, 2015 at 1:30 PM, Peter Geoghegan wrote:
> You should try it with the data fully sorted like this, but with one
> tiny difference: The very last tuple is out of order. How does that
> look?
Another thing that may be of particular interest to you as a Czech
person is how various loc
On Sun, Feb 22, 2015 at 1:19 PM, Tomas Vondra
wrote:
> In short, this fixes all the cases except for the ASC sorted data. I
> haven't done any code review, but I think we want this.
>
> I'll use data from the i5-2500k, but it applies to the Xeon too, except
> that the Xeon results are more noisy a
Over in the abbreviated keys for numeric thread, Tomas Vondra reports
a case where the ad-hoc cost model of abbreviated keys/sortsupport for
text is far too conservative, and aborts a case where abbreviated keys
can still greatly help.
Previously, I proposed additions to the cost model that dealt
20 matches
Mail list logo
