Tom Lane skrev:
Marcus Engene <[EMAIL PROTECTED]> writes:
Should it take 2.5s to sort these 442 rows?
Limit (cost=54.40..54.43 rows=12 width=8) (actual
time=2650.254..2651.093 rows=442 loops=1)
-> Sort (cost=54.40..54.43 rows=12 width=8) (actual
time=2650.251..2650.515 rows
Hi again,
I was thinking, in my slow query it seems the sorting is the villain.
Doing a simple qsort test I notice that:
[EMAIL PROTECTED] /cygdrive/c/pond/dev/tt
$ time ./a.exe 430
real0m0.051s
user0m0.030s
sys 0m0.000s
[EMAIL PROTECTED] /cygdrive/c/pond/dev/tt
$ time ./a.exe 430
Marcus Engene <[EMAIL PROTECTED]> writes:
> Should it take 2.5s to sort these 442 rows?
> Limit (cost=54.40..54.43 rows=12 width=8) (actual
> time=2650.254..2651.093 rows=442 loops=1)
>-> Sort (cost=54.40..54.43 rows=12 width=8) (actual
> time=2650.251..2650.515 rows=442 loops=1)
>
Mike Rylander wrote:
On 8/17/05, Manfred Koizar <[EMAIL PROTECTED]> wrote:
On Mon, 25 Jul 2005 17:50:55 -0400, Kevin Murphy
<[EMAIL PROTECTED]> wrote:
and because the number of possible search terms is so large, it
would be nice if the entire index could somehow be preloaded into memor
On 8/17/05, Manfred Koizar <[EMAIL PROTECTED]> wrote:
> On Mon, 25 Jul 2005 17:50:55 -0400, Kevin Murphy
> <[EMAIL PROTECTED]> wrote:
> > and because the number of possible search terms is so large, it
> >would be nice if the entire index could somehow be preloaded into memory
> >and encouraged to
On Mon, 25 Jul 2005 17:50:55 -0400, Kevin Murphy
<[EMAIL PROTECTED]> wrote:
> and because the number of possible search terms is so large, it
>would be nice if the entire index could somehow be preloaded into memory
>and encouraged to stay there.
Postgres does not have such a feature and I wouldn
