Hello Andres,
Now I cannot see how having one context per table space would have a
significant negative performance impact.
The 'dirty data' etc. limits are global, not per block device. By having
several contexts with unflushed dirty data the total amount of dirty
data in the kernel increases.
Possibly, but how much? Do you have experimental data to back up that
this is really an issue?
We are talking about 32 (context size) * #table spaces * 8KB buffers = 4MB
of dirty buffers to manage for 16 table spaces, I do not see that as a
major issue for the kernel.
Thus you're more likely to see stalls by the kernel moving pages into
writeback.
I do not see the above data having a 30% negative impact on tps, given the
quite small amount of data under discussion, and switching to random IOs
cost so much that it must really be avoided.
Without further experimental data, I still think that the one context per
table space is the reasonnable choice.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
