From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: ShmemAlloc errors |
Date: | 2003-10-17 20:12:05 |
Message-ID: | 87d6cv1v56.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Nick Burrett <nick(at)dsvr(dot)net> writes:
> At the start of the fourth month, the data from the first month is deleted and
> the database vacummed.
When dropping a quarter of the records of a large table you would need a very
large setting free space map. For an occasional periodic job like this you can
just use VACUUM FULL to rebuild the table and free up the space.
> CREATE TABLE fiveminute ( server CHAR(32),
You know CHAR() is space padded, right?
> CREATE UNIQUE INDEX fiveminute_idx ON fiveminute(server,stamp);
>
> It probably would have made sense to just have an index on the server column,
> but I can't remember why (decision was made Nov-2000). I suspect that is the
> cause of the index bloat.
Well, having a unique index is good conceptually because it prevents duplicate
insertions from application errors. But it's probably not worth the
performance hit, given that there are a lot more errors it won't catch.
> The database never survived operational use. The original import of data took
> so long (2+ days) that the re-design was done almost immediately.
How were you importing? The fastest way would be to generate an ascii file in
the format \copy expects.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Marques | 2003-10-17 20:34:46 | Re: restart and postgres.conf |
Previous Message | J Smith | 2003-10-17 19:43:51 | Using subselects in INSERTs? |