[
https://issues.apache.org/jira/browse/DERBY-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-2746:
----------------------------------
I agree that a good place to implement this is in the langauge layer where we
already make some calculations to set
internal defaults based on "guesses" about the static table structure. To do
this this layer is going to have to make some
assumptions about what the storage layer actually does with data. So as you
point out it is problem reasonable to assume
small amount of space (1 byte?) used for storing a null vs. the number of bytes
write exterrnal outputs for a non-null value.
This layer also doesn't really know how what writeExternal of a datatype
corresponds to a specific implementation's on disk
overhead for a column (so in current impl there are per row and per field
overhead and rest is byte for byte what the datatype
writes out, but an alternate implementation could compress the data so on disk
might actually be varying length even for
what the datatype expects is fixed). So reservedSpace is basically just a hint
at what kind of operations the storage engine
should try to optimize for.
The suggestion to even more finely tune the number based on analysis of all the
fields is also interesting.
I agree that alter table later can make these defaults not good anymore. But
the staitic number is not really good either , just a wild
guess currently using no information about the table. If user provided no
default then I think Derby should do the best it can to choose a reasonable
default at the time. This is the same kind of logic added when we try to pick
a reasonable page size default based on the columns in the table. If the user
later adds a CLOB to the table, we may have chosen wrong -- user did have
chance to set it if they wanted to. The good news is that this is just
affects performance, it never will affect whether or not you will be able to
update a row on the table, we automatically will overflow the row if no space
remains on the
table. Also a given conglomerate implementation may be able to accept a
change to this default(this one is likely easier to change than page size), so
that alter table could modify
the default based on the new column. If we were to do this we probably would
need a way to track if the user had explicitly set
a default and we probably should not change it if they did.
Also a few commands result in a reorg of all the data (like compress table),
and it might be reasonable to somehow use that data to see what the actual
existing empty space is and somehow use that to pick a new default. Again if
we did this we should preserve the value if the user explicitly set a value.
> If table only has fixed sized fields then derby should automatically set
> reserved space to 0.
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-2746
> URL: https://issues.apache.org/jira/browse/DERBY-2746
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Mike Matrigali
> Priority: Minor
>
> At create table time the system should be able to tell if all the columns are
> fixed length, and if the user has not set reserved space it should be
> changed to
> 0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
