Re: Problem with query plan

Tom Lane wrote:
> Cott Lang <cott(at)internetstaff(dot)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