Re: Replacement Selection

From: "Timothy J(dot) Kordas" <tkordas(at)greenplum(dot)com>
To: mac_man2005(at)hotmail(dot)it
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Replacement Selection
Date: 2007-11-26 19:09:54
Message-ID: 474B1A02.70800@greenplum.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

mac_man2005(at)hotmail(dot)it wrote:
> I also implemented
> Replacement Selection (RS) so if I'm able to integrate my RS I hope I
> would be able to integrate the others too.

The existing code implements RS. Tom asked you to describe what improvements
you hope to make; I'm confident that he already understands how to implement
RS. :-)

**

Why don't you compile with TRACE_SORT enabled and watch the log output.

The function in tuplesort.c that you should start with is puttuple_common().

in puttuple_common(), the transition from an internal to external sort is
performed at the bottom of the TSS_INITIAL case in the main switch
statement. The function dumptuples() heapifies the in-core tuples (divides
the in-core tuples into initial runs and then advances the state to
TSS_BUILDRUNS). All subsequent tuples will hit the TSS_BUILDRUNS case and
will insert tuples into the heap; emitting tuples for the current run as it
goes.

I recommend you run the code in the debugger on a external-sorting query:
watch two or three tuples go into the heap and you'll get the idea.

The top of the heap is at state->memtuples[0] the heap goes down from there.
New tuples are added there and the heap is adjusted (Using the
tuplesort_heap_siftup() function).

-Tim

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2007-11-26 20:00:52 Re: 8.3devel slower than 8.2 under read-only load
Previous Message Guillaume Smet 2007-11-26 19:04:16 Re: 8.3devel slower than 8.2 under read-only load