Re: Compression and on-disk sorting
От | Jim C. Nasby |
---|---|
Тема | Re: Compression and on-disk sorting |
Дата | |
Msg-id | 20060517154504.GR26212@pervasive.com обсуждение исходный текст |
Ответ на | Re: Compression and on-disk sorting (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Compression and on-disk sorting
Re: Compression and on-disk sorting |
Список | pgsql-hackers |
On Wed, May 17, 2006 at 11:38:05AM -0400, Tom Lane wrote: > "Jim C. Nasby" <jnasby@pervasive.com> writes: > > What *might* make sense would be to provide two locations for pgsql_tmp, > > because a lot of operations in there involve reading and writing at the > > same time: > > > Read from heap while writing tapes to pgsql_tmp > > read from tapes while writing final version to pgsql_tmp > > Note that a large part of the reason for the current logtape.c design > is to avoid requiring 2X or more disk space to sort X amount of data. > AFAICS, any design that does the above will put us right back in the 2X > regime. That's a direct, measurable penalty; it'll take more than > handwaving arguments to convince me we should change it in pursuit of > unquantified speed benefits. I certainly agree that there's no reason to make this change without testing, but if you've got enough spindles laying around to actually make use of this I suspect that requiring 2X the disk space to sort X won't bother you. Actually, I suspect in most cases it won't matter; I don't think people make a habit of trying to sort their entire database. :) But we'd want to protect for the oddball cases... yech. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-hackers по дате отправления: