On Sat, 21 Jun 1997, Bruce Momjian wrote:
> > ExecSort calls psort() to do the work. psort() uses a Knuth algorithm.
> >
> > I removed the psort() call from ExecSort, and the execution time was:
> >
> > Select with order by using psort(): 0.30
> >
> > Select with order by NOT using psort(): 0.07
> >
> > Now of course, not using psort() causes the data not to be sorted, but
> > there must be some inefficienty if sorting one row takes 0.23 seconds on
> > a PP200 with 64MB of RAM. I suspect the other 0.06 seconds is caused by
> > the creation of the temp table and moving the rows around.
>
> It looks like psort()'s use of disk files to do the sorting is causing
> the slowdown, with the multiple create's and unlink's. I am going to
> modify psort() to use memory buffers instead of disk files for sorting
> small SELECT results. psort() is only called by ExecSort, which is used
> by ORDER BY's.
>
> Permission to put this in 6.1p1?
By all means...
My next question is what is considered a 'small SELECT result'? If
I have a 32Meg machine, that 'small' would be different, I would assume,
then a 128Meg machine.
With that in mind, how about some sort of 'switch', similar to
- -B, that allows you to stipulate total RAM of a machine (or virtual memory?),
or something similar to that?
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
------------------------------
