Re: [HACKERS] Tablespace-level Block Size Definitions

2005-06-01 Thread Zeugswetter Andreas DAZ SD
The problem I see with this proposal is that the buffer manager knows how to handle only a equally-sized pages. And the shared memory stuff gets sized according to size * num_pages. So what happens if a certain tablespace A with pagesize=X gets to have a lot of its pages cached, evicting

Re: [HACKERS] Tablespace-level Block Size Definitions

2005-06-01 Thread Dawid Kuroczko
On 6/1/05, Zeugswetter Andreas DAZ SD [EMAIL PROTECTED] wrote: You could create a separate bufferpool per page size. Of course that has other disadvantages. Is it really so difficult to create and attach another shmem segment ? Well, I don't think it is much different from having two

Re: [HACKERS] Tablespace-level Block Size Definitions

2005-06-01 Thread Hannu Krosing
On K, 2005-06-01 at 14:00 +0200, Dawid Kuroczko wrote: On 6/1/05, Zeugswetter Andreas DAZ SD [EMAIL PROTECTED] wrote: You could create a separate bufferpool per page size. Of course that has other disadvantages. Is it really so difficult to create and attach another shmem segment ?

[HACKERS] Tablespace-level Block Size Definitions

2005-05-31 Thread Jonah H. Harris
Hey everyone, I'm sure this has been thought of but was wondering whether anyone had discussed the allowance of run-time block size specifications at the tablespace level? I know that a change such as this would substantially impact buffer operations, transactions, access methods, the

Re: [HACKERS] Tablespace-level Block Size Definitions

2005-05-31 Thread Tom Lane
Jonah H. Harris [EMAIL PROTECTED] writes: I'm sure this has been thought of but was wondering whether anyone had discussed the allowance of run-time block size specifications at the tablespace level? Can you produce any evidence whatsoever that this could be worth the cost? Aside from the

Re: [HACKERS] Tablespace-level Block Size Definitions

2005-05-31 Thread Bricklen Anderson
Jonah H. Harris wrote: Hey everyone, I'm sure this has been thought of but was wondering whether anyone had discussed the allowance of run-time block size specifications at the tablespace level? I know that a change such as this would substantially impact buffer operations, transactions,

Re: [HACKERS] Tablespace-level Block Size Definitions

2005-05-31 Thread Jonah H. Harris
Yes, That is what I/my clients have been discussing. It is a nifty performance feature. Bricklen Anderson wrote: Jonah H. Harris wrote: Hey everyone, I'm sure this has been thought of but was wondering whether anyone had discussed the allowance of run-time block size specifications at

Re: [HACKERS] Tablespace-level Block Size Definitions

2005-05-31 Thread Alvaro Herrera
On Tue, May 31, 2005 at 02:55:29PM -0600, Jonah H. Harris wrote: Hey everyone, I'm sure this has been thought of but was wondering whether anyone had discussed the allowance of run-time block size specifications at the tablespace level? I know that a change such as this would

Re: [HACKERS] Tablespace-level Block Size Definitions

2005-05-31 Thread Jonah H. Harris
Tom, You and I both know that depending on the application and data, different block sizes are beneficial. As for actual statistics due to overhead, I don't know what I can give you. I can provide stats from an application which fits the case for multiple block sizes on Oracle, but Oracle

Re: [HACKERS] Tablespace-level Block Size Definitions

2005-05-31 Thread Simon Riggs
On Tue, 2005-05-31 at 17:05 -0400, Tom Lane wrote: Jonah H. Harris [EMAIL PROTECTED] writes: I'm sure this has been thought of but was wondering whether anyone had discussed the allowance of run-time block size specifications at the tablespace level? Can you produce any evidence