Re: 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" <jharris(at)tvi(dot)edu> 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
>
>