From: | <mac_man2005(at)hotmail(dot)it> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Polyphase Merge |
Date: | 2008-01-22 17:44:57 |
Message-ID: | BAY132-DS1DBBC44FF78A6C9B6C816E63E0@phx.gbl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
--------------------------------------------------
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Sent: Monday, January 21, 2008 10:13 PM
To: "Sam Mason" <sam(at)samason(dot)me(dot)uk>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Polyphase Merge
>
> I agree --- having to read the run back from external storage, only to
> write it out again with no further useful work done on it, sounds like
> a guaranteed loser. To make this work you'll need some kind of ju-jitsu
> rearrangement that logically puts the run where it needs to go without
> physically moving any data.
I'm not going to write it back with no useful work on it. I should just
write them in reverse order during run formation (ju-jitsu couldn't help me
in this case) or read them in reverse order while merging (ju-jitsu may
help... the point is that I'm not so good in ju-jitsu).
An idea could be managing a list of pointers to runs contained into tapes.
Any comment?
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Smet | 2008-01-22 18:52:04 | Suboptimal plan choice problem with 8.3RC2 |
Previous Message | Patrick McPhee | 2008-01-22 17:00:42 | Re: Password policy |