Re: Migration study, step 1: bulk write performance
От
Jim C. Nasby
Тема
Re: Migration study, step 1: bulk write performance
Дата
Msg-id
20060321121839.GT15742@pervasive.com
Ответ на
Re: Migration study, step 1: bulk write performance (Steinar H. Gunderson)
Список
Дерево обсуждения
Migration study, step 1: bulk write performance optimization "Mikael Carneholm" <Mikael.Carneholm@WirelessCar.com>
Re: Migration study, step 1: bulk write performance Csaba Nagy <nagy@ecircle-ag.com>
Re: Migration study, step 1: bulk write performance "Jim C. Nasby" <jnasby@pervasive.com>
Re: Migration study, step 1: bulk write performance Csaba Nagy <nagy@ecircle-ag.com>
Re: Migration study, step 1: bulk write performance "Steinar H. Gunderson" <sgunderson@bigfoot.com>
Re: Migration study, step 1: bulk write performance Csaba Nagy <nagy@ecircle-ag.com>
Re: Migration study, step 1: bulk write performance "Jim C. Nasby" <jnasby@pervasive.com>
Re: Migration study, step 1: bulk write performance "Steinar H. Gunderson" <sgunderson@bigfoot.com>
Re: Migration study, step 1: bulk write performance "Jim C. Nasby" <jnasby@pervasive.com>
Re: Migration study, step 1: bulk write performance "Steinar H. Gunderson" <sgunderson@bigfoot.com>
Re: Migration study, step 1: bulk write performance "Jim C. Nasby" <jnasby@pervasive.com>
Re: Migration study, step 1: bulk write performance Michael Stone <mstone+postgres@mathom.us>
Re: Migration study, step 1: bulk write performance Simon Riggs <simon@2ndquadrant.com>
Re: Migration study, step 1: bulk write performance Ron <rjpeace@earthlink.net>
Re: Migration study, step 1: bulk write performance Scott Marlowe <smarlowe@g2switchworks.com>
Re: Migration study, step 1: bulk write performance Tom Lane <tgl@sss.pgh.pa.us>
Re: Migration study, step 1: bulk write performance Scott Marlowe <smarlowe@g2switchworks.com>
Re: Migration study, step 1: bulk write performance Alvaro Herrera <alvherre@commandprompt.com>
Re: Migration study, step 1: bulk write performance optimization "Craig A. James" <cjames@modgraph-usa.com>
update == delete + insert? "Craig A. James" <cjames@modgraph-usa.com>
Re: update == delete + insert? "Jim Buttafuoco" <jim@contactbda.com>
Re: update == delete + insert? Tom Lane <tgl@sss.pgh.pa.us>
Re: update == delete + insert? "Jaime Casanova" <systemguards@gmail.com>
Re: update == delete + insert? "Jim C. Nasby" <jnasby@pervasive.com>
Re: update == delete + insert? "Merlin Moncure" <mmoncure@gmail.com>
Re: update == delete + insert? "Jim C. Nasby" <jnasby@pervasive.com>
Re: Migration study, step 1: bulk write performance optimization Tom Lane <tgl@sss.pgh.pa.us>
Re: Migration study, step 1: bulk write performance optimization Dave Cramer <pg@fastcrypt.com>
Re: Migration study, step 1: bulk write performance optimization PFC <lists@peufeu.com>
On Tue, Mar 21, 2006 at 01:10:32PM +0100, Steinar H. Gunderson wrote: > On Tue, Mar 21, 2006 at 06:01:58AM -0600, Jim C. Nasby wrote: > > Are you sure? Metadate changes are probably a lot more common on the WAL > > partition. In any case, I don't see why there should be a difference. > > The real issue is: is related filesystem metadata sync'd as part of a > > file being fsync'd? > > I've been told on this list that PostgreSQL actually takes care to fill a new > WAL file with zeroes etc. when initializing it; dig a few months back and I'm > sure it's there. That's fine and all, but does no good if the filesystem doesn't know that the file exists on a crash. The same concern is also true on the data partition, although it's less likely to be a problem because if you happen to crash soon after a DDL operation it's likely that you haven't had a checkpoint yet, so the operation will likely be repeated during WAL replay. But depending on that is a race condition. Basically, you need to know for certain that if PostgreSQL creates a file and then fsync's it that that file is safely on disk, and that the filesystem knows how to find it (ie: the metadata is also on disk in some fashion). -- 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-performance по дате отправления
От: Steinar H. Gunderson
Дата: