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 segme

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 da

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, > evicti

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 evi

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 a

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 substant

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 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, acc

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

[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 storage