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
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 |