"Tom Lane" <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> 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, 100);
On Sat, 2007-04-07 at 22:16 -0400, Bruce Momjian wrote:
> > The patch is faster until we hit 100k or 10% of the table, at which
> > point it is the same speed. What is interesting is 1M is also the same
> > speed:
All tests good, AFAICS. Thanks Bruce.
Patch is operating as expected: the common
Oh, sorry, forgot to do a random table test. The test used:
DROP TABLE test;
CREATE TABLE test (x INTEGER);
INSERT INTO test SELECT random()*100 FROM generate_series(1,
100);
As expected the unpatched version is consistent for all LIMIT values
(first query was s
I reran the test using:
test=> CREATE TABLE test (x INTEGER);
test=> INSERT INTO test SELECT * FROM generate_series(1, 100);
test=> SET log_min_duration_statement = 0;
and got on an unpatched system:
1751.320 ms select * from (select * from test order by x l
On Sat, 2007-04-07 at 14:11 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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(
Bruce Momjian <[EMAIL PROTECTED]> 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, 100);
> test=> SET log_min_duration_statement
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, 100);
test=> SET log_min_duration_statement = 0;
test=> SELECT * FROM test ORDER
Updated patch attached:
1) Removes #if 0 optimizations
2) Changes #if 0 to #if NOT_USED for code that's there for completeness and to
keep the code self-documenting purposes rather but isn't needed by anything
currently
3) Fixed cost model to represent bounded sorts
sort-limit-v7.patc
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Some comments on the patch below.
Thanks!
> Gregory Stark wrote:
>
>
>
> The comment claims that we use heap sort when the user says he doesn't want to
> use glibc's qsort. I recall that we always use our own qsort implementation
> nowadays. And
Some comments on the patch below.
Gregory Stark wrote:
+ /* tuplesort_set_bound - External API to set a bound on a tuplesort
+ *
+ * Must be called before inserting any tuples.
+
+ * Sets a maximum number of tuples the caller is interested in. The first
+ * tuples are maintained using a
Gregory Stark wrote:
> >> Did Greg push a version which didn't carry the "WIP" label to it? As
> >> far as I remember he was still asking how to make the Sort and Limit
> >> nodes communicate.
> >
> > Good question. I asked for a new version of this patch and the WIP was
> > only in the email sub
>> Did Greg push a version which didn't carry the "WIP" label to it? As
>> far as I remember he was still asking how to make the Sort and Limit
>> nodes communicate.
>
> Good question. I asked for a new version of this patch and the WIP was
> only in the email subject line. Greg, is this ready fo
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > Your patch has been added to the PostgreSQL unapplied patches list at:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches
> >
> > It will be applied as soon as one of the PostgreSQL committers reviews
> > and approves it.
>
> Did Gre
Bruce Momjian wrote:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers reviews
> and approves it.
Did Greg push a version which didn't carry the
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Gr
On Wed, 2007-03-14 at 15:16 +, Gregory Stark wrote:
> Do people prefer receiving attachments or downloadable links?
Attachments are very clearly submissions to the project.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broa
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Do people prefer receiving attachments or downloadable links?
>> Does the answer change if the patches are quite large?
>
> Links suck from an archival standpoint; but at the same time you need
> to pay some attention to the size of y
Gregory Stark <[EMAIL PROTECTED]> writes:
> Do people prefer receiving attachments or downloadable links?
> Does the answer change if the patches are quite large?
Links suck from an archival standpoint; but at the same time you need
to pay some attention to the size of your email. I think the cu
"Gregory Stark" <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
>> Is there a newer version of this patch?
>
> As requested, I've cut an updated version of this patch against CVS HEAD:
>
> http://community.enterprisedb.com/sort-limit-v5.patch.gz
Someone asked why I've
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is there a newer version of this patch?
As requested, I've cut an updated version of this patch against CVS HEAD:
http://community.enterprisedb.com/sort-limit-v5.patch.gz
The open issues I see are:
Adjusting the costing of the sort to take into ac
Is there a newer version of this patch?
---
Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2007-02-07 at 10:49 +, Gregory Stark wrote:
> > > The two open issues (which are arguably the sa
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Wed, 2007-02-07 at 10:49 +, Gregory Stark wrote:
> > The two open issues (which are arguably the same issue) is how to get
> > the information down to the sort node and how to cost the plan.
> > Currently it's a bit of a hack: the Limit node peeks
On Wed, 2007-02-07 at 10:49 +, Gregory Stark wrote:
> The two open issues (which are arguably the same issue) is how to get
> the information down to the sort node and how to cost the plan.
> Currently it's a bit of a hack: the Limit node peeks at its child and
> if it's a sort it calls a speci
23 matches
Mail list logo
