On Wed, 2008-01-09 at 15:53 +0000, Gregory Stark wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> 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.
Which is exactly what we do with DROP FUNCTION...
You'd run these things as often as you run ALTER TABLE SET tablespace,
so it doesn't seem a problem.
When I delete all rows WHERE some_date < 'cut-off date' on a segment
boundary value that would delete all segments that met the criteria. The
following VACUUM will then return those segments to be read-write, where
they can then be refilled with new incoming data. The only command we
would have to run is the DELETE, everything else is automatic.
If we have named chunks, then you'd have to specifically reset the
boundary conditions on the named chunk after deletion before the chunk
could be reused. That all becomes DDL, which means additional code to be
written, bugs to be fixed, as well as the table locking required. Seems
like a lot just for some occasional convenience.
So not convinced of the need for named sections of tables yet. It all
seems like detail, rather than actually what we want for managing large
tables.
-- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
