Re: [HACKERS] What I'm working on
От | The Hermit Hacker |
---|---|
Тема | Re: [HACKERS] What I'm working on |
Дата | |
Msg-id | Pine.BSF.4.02.9808232252550.295-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] What I'm working on (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] What I'm working on
|
Список | pgsql-hackers |
On Sun, 23 Aug 1998, Bruce Momjian wrote: > Most filesystem base block sizes are 8k. Making anything larger is not > going to gain much. I don't think we can support block sizes like 12k > because the filesystem is going to sync stuff in 8k chunks. > > Seems like we should do the most user-transparent thing and just allow > spanning rows. The blocksize patch wasn't a "user-land" feature, its an admin level...no? The admin sets it at the createdb level...no? Again, I'm curious as to why either/or is mutual exclusive? Let's put it this way, from a performance perspective, which one would provide more? Again, I'm thinking of this from the admin angle, not user. I create a database whose tuples, in general, exceed 8k. vacuum kindly tells me this, so, to improve performance, I dump my databases, and because this is a specialized application, its on its own file system. So, I reformat that drive with a larger blocksize, to match the blocksize I'm about to set my database to (yes, I do do similar to this to optimize file systems for news, so it isn't too hypothetical)... Bear in mind, I am not arguing for one of them, I'm arguing for both of them...unless there is some architectural reason why both can't be implemented at the same time...? Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
В списке pgsql-hackers по дате отправления: