Re: [PATCHES] 2WRS [WIP] - Mailing list pgsql-hackers

From
Subject Re: [PATCHES] 2WRS [WIP]
Date
Msg-id BAY112-DS21A7A11EDC20DAD5267C9E6190@phx.gbl
Whole thread Raw
In response to Re: [PATCHES] 2WRS [WIP]  ("Jaime Casanova" <systemguards@gmail.com>)
List pgsql-hackers
For the joy of all of you: that's the correct WIP patch.
At the moment it only tries to create runs uding two heaps. Hope you can
help me with writing those runs on tapes.

I'd be very pleased to give you more details.

Thenks for your time.
Regards, Manolo.

--------------------------------------------------
From: "Jaime Casanova" <systemguards@gmail.com>
Sent: Friday, February 22, 2008 5:30 AM
To: <manolo.espa@gmail.com>
Cc: "Decibel!" <decibel@decibel.org>; "Manolo _" <mac_man2005@hotmail.it>;
"David Fetter" <david@fetter.org>; <pgsql-patches@postgresql.org>;
<pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] [PATCHES] 2WRS [WIP]

> On Thu, Feb 21, 2008 at 6:44 AM,  <manolo.espa@gmail.com> wrote:
>> Hi.
>>
>> That's the last release and refers to 8.3.0 and not to 8.2.5 as before.
>> Hope
>> you can tell me if I created it correctly please.
>>
>
> no, it doesn't...
>
>> ! /* GUC variables */
>>   #ifdef TRACE_SORT
>>   bool trace_sort = false;
>>   #endif
>> - #ifdef DEBUG_BOUNDED_SORT
>> - bool optimize_bounded_sort = true;
>> - #endif
>
> it's seems you're removing something added in 8.3
>
> --
> regards,
> Jaime Casanova
>
> "Programming today is a race between software engineers striving to
> build bigger and better idiot-proof programs and the universe trying
> to produce bigger and better idiots.
> So far, the universe is winning."
> Richard Cook
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>       choose an index scan if your joining column's datatypes do not
>       match
>
Attachment

pgsql-hackers by date:

Previous
From: "Zeugswetter Andreas ADI SD"
Date:
Subject: Re: pg_dump additional options for performance
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_dump additional options for performance