Skip site navigation (1) Skip section navigation (2)

Re: Sort time

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: pginfo <pginfo(at)t1(dot)unisoftbg(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <josh(at)agliodbs(dot)com>,Rod Taylor <rbt(at)rbt(dot)ca>, "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>,"pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Sort time
Date: 2002-11-16 17:15:11
Message-ID: 20021116091337.U26137-100000@megazone23.bigpanda.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Sat, 16 Nov 2002, pginfo wrote:

> Hi,
>
> Tom Lane wrote:
>
> > Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > > Here's a question: is the total size of the column a good indicator of the
> > > sort_mem required?   Or does the rowsize affect it somehow?
> >
> > It will include all the data that's supposed to be output by the sort...
> > both the key column(s) and the others.
> >
>
> Hmm it is not clear for me.Let we have all data.
> If I make sort by S.OP ( it is INT) it take < 6 sek for sort.
> I think we move all this data anly the number of comparation is by INT. I think
> the number of comparation
> is ~ n * ln(n).
> If we sort by S.IDS_xxx we have also n*ln(n) comparations but in
> varchar(string).
> I don't think that it can take 50 sek.
>
> Is it not so?

Have you tried setting up another database in "C" locale and compared the
timings there?  I'd wonder if maybe there's some extra copying going on
given the comments in varstr_cmp.


In response to

Responses

pgsql-performance by date

Next:From: pginfoDate: 2002-11-17 06:30:28
Subject: Re: Sort time
Previous:From: pginfoDate: 2002-11-16 06:36:52
Subject: Re: Sort time

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group