Re: polyphase merge?
От | Don Marvick |
---|---|
Тема | Re: polyphase merge? |
Дата | |
Msg-id | d18e24870902041854l4fb3c469if476796f918dd1a2@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: polyphase merge? (Gregory Stark <stark@enterprisedb.com>) |
Список | pgsql-hackers |
Hmm probably it's worth to try this. Has anybody try this before? If not, I am interested to give it a try.<br /><br />Regards,<br/><br />Don<br /><br /><div class="gmail_quote">On Wed, Feb 4, 2009 at 11:25 PM, Gregory Stark <span dir="ltr"><<ahref="mailto:stark@enterprisedb.com">stark@enterprisedb.com</a>></span> wrote:<br /><blockquote class="gmail_quote"style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><divclass="Ih2E3d">Simon Riggs <simon@2ndQuadrant.com> writes:<br /><br /> > On Wed, 2009-02-04 at 10:55 +0000,Greg Stark wrote:<br /> >> Is this basically the same as our current algorithm but without<br /> >> multiplexingthe tapes onto single files? I have been wondering<br /> >> whether we multiplex the tapes any better thanfilesystems can lay out<br /> >> separate files actually.<br /> ><br /> > I don't think you'll be able todo that more efficiently than we already<br /> > do. Read the top of tuplesort.c<br /><br /></div>Huh?<br /><br /> Thequestion I posed was whether we do it any better than filesystems do, not<br /> whether we could do a better job. If filesystemscan do as good a job then we<br /> might as well create separate files for each tape and let the filesystem<br/> decide where to allocate space. That would mean we could massively simplify<br /> logtape.c and just createa separate file for every tape.<br /><br /> Possible reasons that filesystems could do better than us are that theyhave<br /> access to more information about actual storage layout on disk, that they have<br /> more information abouthardware characteristics, and that it would give the<br /> filesystem cache a better idea of the access pattern whichlogtape.c might be<br /> confusing the picture of currently.<br /><br /> On the other hand possible reasons why filesystemswould suck at this include<br /> creating and deleting new files being a slow or locking operation on many<br/> filesystems, and dealing with directories of large numbers of files being<br /> poorly optimized on others.<br/><font color="#888888"><br /> --<br /> Gregory Stark<br /> EnterpriseDB <a href="http://www.enterprisedb.com"target="_blank">http://www.enterprisedb.com</a><br /> Ask me about EnterpriseDB's RemoteDBAservices!<br /></font></blockquote></div><br />
В списке pgsql-hackers по дате отправления: