Bruce Momjian wrote:
Peter Eisentraut wrote:
Joe Conway writes:
Any more thoughts on block_size (or page_size)?
It's always been some variant spelling of "block size", and I see no
reason to change the terminology.
Yes, that is from a coder's perspective, but from the user/admin
perspective, it see
Peter Eisentraut wrote:
> Joe Conway writes:
>
> > Any more thoughts on block_size (or page_size)?
>
> It's always been some variant spelling of "block size", and I see no
> reason to change the terminology.
Yes, that is from a coder's perspective, but from the user/admin
perspective, it seems m
Joe Conway writes:
> Any more thoughts on block_size (or page_size)?
It's always been some variant spelling of "block size", and I see no
reason to change the terminology.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 8: e
Bruce Momjian wrote:
Any more thoughts on block_size (or page_size)?
When I think of block size I think of disk blocks, and when I think of
pages I think of memory pages. Unfortunately, neither is a database
page.
I guess my point is that we have heap pages and index pages, but no one
calls them h
Joe Conway wrote:
> Bruce Momjian wrote:
> > Joe Conway wrote:
> >>The description is a statement because the option is boolean, i.e. the
> >>statement "Datetimes are integer based" is either "true" or "false"
> >>("on" or "off", etc). How stongly do you feel about it? I don't think
> >>"integer
Bruce Momjian wrote:
Joe Conway wrote:
The description is a statement because the option is boolean, i.e. the
statement "Datetimes are integer based" is either "true" or "false"
("on" or "off", etc). How stongly do you feel about it? I don't think
"integer_datetime_storage" is accurate in any ca
Joe Conway wrote:
> >>name | func_max_args
> >>name | index_max_keys
> > Should that be max_func_args and max_index_args? Seems more natural.
> > Should we spell out function? Probably. We already have
> > check_*function*_bodies.
>
> Agreed. Now:
> name | max_function_args
>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> There was just a discussion a few days ago about the page size for large
>> objects, for which the correct answer was "BLCKSZ/4" IIRC. Whether
>> people actually *should* care about the page size of large objects I
>> dunno, but th
Tom Lane writes:
> There was just a discussion a few days ago about the page size for large
> objects, for which the correct answer was "BLCKSZ/4" IIRC. Whether
> people actually *should* care about the page size of large objects I
> dunno, but the fact is some of them *do* care.
Maybe we should
Bruce Momjian wrote:
Joe Conway wrote:
name | block_size
OK. Should that be page_size? Not sure but block size sounds more like
a hardware setting. I know we call it BLCKSZ in our code but page size
seems more appropriate. Not sure.
Seems like block_size is more appropriate to me. Any oth
Joe Conway wrote:
> Tom Lane wrote:
> > One could make a good case that INDEX_MAX_KEYS should be exported along
> > with FUNC_MAX_ARGS, rather than letting people write client code that
> > assumes they are the same.
> >
> > I was intending to propose that we also export the following as
> > read-
Joe Conway <[EMAIL PROTECTED]> writes:
> It will require an initdb -- should I hold off for other
> pending changes also requiring initdb?
No, there's no particular reason to avoid initdbs during development
cycles. That's why we have catversion in the first place ...
re
Tom Lane wrote:
Perhaps the GUC variable name should be max_name_len or some such.
Also, should func_max_args and index_max_keys become max_func_args and
max_index_keys?
That sounds good to me:
-[ RECORD 3 ]--
name | max_func_args
setting| 32
Joe Conway <[EMAIL PROTECTED]> writes:
> name | name_data_len
> setting| 63
> short_desc | Shows the maximum identifier length
Defining the value as NAMEDATALEN-1 is reasonable (I was thinking of
suggesting that myself), but it seems like a recipe for confusion to
use name_data_len to re
Tom Lane wrote:
One could make a good case that INDEX_MAX_KEYS should be exported along
with FUNC_MAX_ARGS, rather than letting people write client code that
assumes they are the same.
I was intending to propose that we also export the following as
read-only variables:
* NAMEDATALEN
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > One could make a good case that INDEX_MAX_KEYS should be exported along
> > with FUNC_MAX_ARGS, rather than letting people write client code that
> > assumes they are the same.
>
> You can determine these values by looking into the system catalogs.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> One could make a good case that INDEX_MAX_KEYS should be exported along
>> with FUNC_MAX_ARGS, rather than letting people write client code that
>> assumes they are the same.
> You can determine these values by looking into the sys
Tom Lane writes:
> One could make a good case that INDEX_MAX_KEYS should be exported along
> with FUNC_MAX_ARGS, rather than letting people write client code that
> assumes they are the same.
You can determine these values by looking into the system catalogs.
> I was intending to propose that we
Joe Conway <[EMAIL PROTECTED]> writes:
> First installment. The attached exports FUNC_MAX_ARGS as a read-only GUC
> variable -- func_max_args. Comments?
One could make a good case that INDEX_MAX_KEYS should be exported along
with FUNC_MAX_ARGS, rather than letting people write client code that
as
19 matches
Mail list logo
