Re: [HACKERS] Tablespace-level Block Size Definitions
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 pages from tablespace B with pagesize=Y, where Y X? 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 ? Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Tablespace-level Block Size Definitions
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 database clusters, each with different block size. Hmm, perhaps it could be possible to make them all available through one virtual DB host/port using pg_pool even. :) It shouldn't be too difficult to create benchmarks testing performance of PostgreSQL under different block sizes, I guess. I wonder what perfromance win is possible... Regards, Dawid ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Tablespace-level Block Size Definitions
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 ? Well, I don't think it is much different from having two database clusters, each with different block size. Hmm, perhaps it could be possible to make them all available through one virtual DB host/port using pg_pool even. :) It shouldn't be too difficult to create benchmarks testing performance of PostgreSQL under different block sizes, I guess. I wonder what perfromance win is possible... Perhaps it is simpler to just put different tablespaces on different disks and then play with filesystem readahead settings at disk level. It's not exactly the same thing, but may solve at least some problems. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Tablespace-level Block Size Definitions
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 manager, and a lot of other stuff, however it would give an administrator the ability to inhance performance for specific applications. Arguably, one can set the block size at compile-time, but for a system running multiple databases it *may* be a nice feature. Would it be used a lot? Probably not. Would I use it? Certainly! Would some of my clients use it? Yes. Perhaps a TODO item for some advantageous company to fund? -Jonah ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Tablespace-level Block Size Definitions
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 nontrivial development effort needed, there would be runtime inefficiencies created --- for instance, inefficient use of buffer pool storage because it'd no longer be true that any buffer could hold any block. Without some pretty compelling evidence, I wouldn't even waste any time thinking about it ... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Tablespace-level Block Size Definitions
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, access methods, the storage manager, and a lot of other stuff, however it would give an administrator the ability to inhance performance for specific applications. Arguably, one can set the block size at compile-time, but for a system running multiple databases it *may* be a nice feature. Would it be used a lot? Probably not. Would I use it? Certainly! Would some of my clients use it? Yes. Perhaps a TODO item for some advantageous company to fund? -Jonah Have you used Oracle's version as well? -- ___ This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. ___ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Tablespace-level Block Size Definitions
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 the tablespace level? I know that a change such as this would substantially impact buffer operations, transactions, access methods, the storage manager, and a lot of other stuff, however it would give an administrator the ability to inhance performance for specific applications. Arguably, one can set the block size at compile-time, but for a system running multiple databases it *may* be a nice feature. Would it be used a lot? Probably not. Would I use it? Certainly! Would some of my clients use it? Yes. Perhaps a TODO item for some advantageous company to fund? -Jonah Have you used Oracle's version as well? ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Tablespace-level Block Size Definitions
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 substantially impact buffer operations, transactions, access methods, the storage manager, and a lot of other stuff, however it would give an administrator the ability to inhance performance for specific applications. 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 pages from tablespace B with pagesize=Y, where Y X? While I think it could be workable to make the buffer manager handle variable-sized pages, it could prove difficult to handle the shared memory. (We can't resize it while the server is running.) -- Alvaro Herrera (alvherre[a]surnet.cl) La principal caracterÃstica humana es la tonterÃa (Augusto Monterroso) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Tablespace-level Block Size Definitions
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 accounts for this overhead anyway. I can give you academic research studies, which may be fairly unreliable in a real-world setting. I don't disagree at all that supporting multiple block sizes would be one big PITA to implement and that it would add overhead. I am just saying that it would be a useful feature for *some* people. Granted, this isn't a large population (at this point in time), but applications have been written and optimized using these features. You are all really smart and I'm just putting this suggestion out there to stew on. I don't want you guys to think that I'm just throwing out every Oracle feature I can find, just that when I'm working on an application which benefits from a feature which would similarly be useful in PostgreSQL, I suggest it. You guys have been working on pgsql far longer than I, so for my ideas, chew 'em up and spit 'em out, I don't take offense. As I stated initially, this wouldn't even be a low-priority thing, just a nicety that IMHO would be well-placed in a TODO (possibly as investigate usability and feasability of block sizes by tablespace). Tom, I respect your insight and would be more than happy to get you any information you'd like concerning this subject or any other I may suggest. I don't want to waste your time, so if there is anything in particular you want to see, just let me know. Thanks. -Jonah 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 whatsoever that this could be worth the cost? Aside from the nontrivial development effort needed, there would be runtime inefficiencies created --- for instance, inefficient use of buffer pool storage because it'd no longer be true that any buffer could hold any block. Without some pretty compelling evidence, I wouldn't even waste any time thinking about it ... regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Tablespace-level Block Size Definitions
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 whatsoever that this could be worth the cost? Aside from the nontrivial development effort needed, there would be runtime inefficiencies created --- for instance, inefficient use of buffer pool storage because it'd no longer be true that any buffer could hold any block. Without some pretty compelling evidence, I wouldn't even waste any time thinking about it ... DB2 has had multiple page size support for some time, though the default was always 4KB. They have just reintroduced the option to have a single page size 4KB across the database. They would not do this if there was not clear evidence that multiple block sizes were inefficient in some reasonably common cases. I must admit when I cam here, I thought the same as Jonah. But the I haven't seen any recent evidence for any benefit. Its a real pain trying to test this and very difficult to change once its been setup. There's a great deal more benefit to be had from many other areas, IMHO. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
