Re: Problem with query plan

Tom Lane wrote:
> Cott Lang <cott@internetstaff.com> writes:
>
>>Fiddling with the above values, only setting sort_mem absurdly large
>>easily causes NAN.
>
>
> Ah.  I see an overflow case for sort_mem exceeding 1Gb; that's probably
> what you tickled.
>
> I've fixed this in HEAD, but it doesn't seem worth back-patching.
> If you care, the change in HEAD is
>
> *** src/backend/optimizer/path/costsize.c.orig    Sun Aug 29 01:06:43 2004
> --- src/backend/optimizer/path/costsize.c    Fri Oct 22 20:02:39 2004
> ***************
> *** 566,572 ****
>       if (nbytes > work_mem_bytes)
>       {
>           double        npages = ceil(nbytes / BLCKSZ);
> !         double        nruns = nbytes / (work_mem_bytes * 2);
>           double        log_runs = ceil(LOG6(nruns));
>           double        npageaccesses;
>
> --- 566,572 ----
>       if (nbytes > work_mem_bytes)
>       {
>           double        npages = ceil(nbytes / BLCKSZ);
> !         double        nruns = (nbytes / work_mem_bytes) * 0.5;
>           double        log_runs = ceil(LOG6(nruns));
>           double        npageaccesses;
>
>
> but the variable names have changed since 7.4 so this won't apply
> cleanly.

If somebody care about apply this for 7.4, here there is the equivalent change:


--- costsize.c.orig     2004-10-23 11:17:38.000000000 +0200
+++ costsize.c  2004-10-23 11:19:04.000000000 +0200
@@ -548,7 +548,7 @@
         if (nbytes > sortmembytes)
         {
                 double          npages = ceil(nbytes / BLCKSZ);
-               double          nruns = nbytes / (sortmembytes * 2);
+               double          nruns = ( nbytes / sortmembytes ) * 0.5 ;
                 double          log_runs = ceil(LOG6(nruns));
                 double          npageaccesses;









Regards
Gaetano Mendola