Re: Migration study, step 1: bulk write performance optimization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



using a 16kb block size (for read performance) will probably be considered as well.

Hm, this means that when postgres wants to write just one 8k page, the OS will have to read 16k, replace half of it with the new block, and write 16k again... I guess it should be better to stick with the usual block size. Also, it will have to read 16k every time it rally wants to read one page... which happens quite often except for seq scan.

NOTE: this machine/configuration is NOT what we will be using in production if the study turns out OK, it's just supposed to work as a development machine in the first phase whose purpose more or less is to get familiar with configurating Postgres and see if we can get the application up and running (we will probably use a 64bit platform and

	Opteron xDDD

Use XFS or Reiser... ext3 isn't well suited for this. use noatime AND nodiratime.

	It's safe to turn off fsync while importing your data.
	For optimum speed, put the WAL on another physical disk.

Look in the docs which of maintenance_work_mem, or work_mem or sort_mem is used for index creation, and set it to a very large value, to speed up that index creation. Create your indexes with fsync=off also.




[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux