On Wed, 2008-01-09 at 15:53 +0000, Gregory Stark wrote: > "Simon Riggs" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
