Re: LIMIT/SORT optimization

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Gregory Stark <gsstark(at)mit(dot)edu>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: LIMIT/SORT optimization
Date: 2007-04-07 18:11:48
Message-ID: 10816.1175969508@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> I did some performance testing of the patch, and the results were good.
> I did this:

> test=> CREATE TABLE test (x INTEGER);
> test=> INSERT INTO test SELECT * FROM generate_series(1, 1000000);
> test=> SET log_min_duration_statement = 0;
> test=> SELECT * FROM test ORDER BY x LIMIT 3;

LIMIT 3 seems an awfully favorable case; if the patch can only manage a
factor of 4 speedup there, what happens at limit 10, 20, 100? Also,
you've tested only one sort size and only one (unspecified) value of
work_mem, and the usefulness of the patch would surely vary depending on
that. In particular, what happens with a LIMIT large enough to overflow
work_mem?

Lastly, I suspect that sorting presorted input might be particularly
favorable for this patch. Please try it with random data for comparison.

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2007-04-07 20:37:53 Re: RESET SESSION v2
Previous Message Tom Lane 2007-04-07 18:02:24 Re: simply custom variables protection