"Simon Riggs" <simon@2ndquadrant.com> writes:
> On Wed, 2008-01-09 at 02:25 +0000, Gregory Stark wrote:
>
>> Without naming the DBA would have to specify the same ranges every time he
>> wants to change the properties. He might do a "SET read_only WHERE created_on
>> < '2000-01-01'" one day then another "SET tablespace tsslow WHERE created_on <
>> '2000-01-01'" and then later again do "SET offline WHERE created_on <
>> '2000-01-01'"
>>
>> I have to admit I always found it kludgy to have objects named
>> invoices_2000_JAN and invoices_2000_FEB and so on. It's kind of an meta
>> denormalization. But so is specifying where clauses repeatedly.
>
> The idea for using the WHERE clauses was to specifically avoid naming.
>
> In most cases the table is divided into old read only and newer data. So
> there is one split point that make it easy to use a simple WHERE clause.
>
> If you guys really want names, we can have names, but I think I want to
> see a case where the storage characteristics of the table are so complex
> we can only make sense of it by naming particular chunks.
Perhaps a good analogy is indexes. Index names are themselves kind of
redundant and people usually use names which encode up most of the information
of the definition.
But the reason you need names for indexes is so that you can refer to them
later to drop them, rebuild them, change their properties such as tablespace,
fill factor, etc?
You could imagine imposing on users that they should restate the index
definition every time they want to change the fill factor or tablespace but
I'm sure you could see the downsides with that approach.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production
Tuning