Re: Replacement Selection

Поиск
Список
Период
Сортировка
От
Тема Re: Replacement Selection
Дата
Msg-id BAY132-DS30F1930B2A37D80D98377E6750@phx.gbl
обсуждение исходный текст
Ответ на Autovacuum and OldestXmin  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Replacement Selection  ("Timothy J. Kordas" <tkordas@greenplum.com>)
Re: Replacement Selection  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Replacement Selection  (<mac_man2005@hotmail.it>)
Re: Replacement Selection  (<mac_man2005@hotmail.it>)
Re: Replacement Selection  (<mac_man2005@hotmail.it>)
Список pgsql-hackers
I must precise that it's not the improvement. Other more complex algorithms 
correspond to the refinements, but at the moment I just want to know which 
part of PostgreSQL code does what. 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.

Anyway, even in my RS implementation a longer run is created. The first M 
initialization elements will surely form part of the current run. M is the 
memory size so at least a run sized M will be created. After initialization, 
the elements are not suddenly output, but an element from heap is output 
into run as soon as I get an element from stream. In other words, for each 
element from stream, the root element of the heap is output, and the input 
element takes the root place into the heap. If that element is a "good 
record" I just heapify (since the element will be placed at the now free 
root place). If that input element is a dead record I swap it with the last 
leaf and reduce the heap size.



--------------------------------------------------
From: "Tom Lane" <tgl@sss.pgh.pa.us>
Sent: Monday, November 26, 2007 7:31 PM
To: <mac_man2005@hotmail.it>
Cc: <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Replacement Selection

> <mac_man2005@hotmail.it> writes:
>> 3) Start run generation. As for this phase, I see PostgreSQL code (as 
>> Knuth
>> algorithm) marks elements belonging to runs in otder to know which run 
>> they
>> belong to and to know when the current heap has finished building the
>> current run. I don't memorize this kind of info. I just output from heap 
>> to
>> run all of the elements going into the current run. The elements supposed 
>> to
>> go into the next run (I call them "dead records") are still stored into 
>> main
>> memory, but as leaves of the heap. This implies reducing the heap size 
>> and
>> so heapifying a smaller number of elements each time I get a dead record
>> (it's not necessary to sort dead records). When the heap size is zero a 
>> new
>> run is created heapifying all the dead records currently present into 
>> main
>> memory.
>
> Why would this be an improvement over Knuth?  AFAICS you can't generate
> longer runs this way, and it's not saving any time --- in fact it's
> costing time, because re-heapifying adds a lot of new comparisons.
>
> regards, tom lane
> 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Replacement Selection
Следующее
От: "Guillaume Smet"
Дата:
Сообщение: Re: 8.3devel slower than 8.2 under read-only load