On Mon, Dec 19, 2005 at 11:10:50AM -0800, James Klo wrote:
Yes, I've considered partitioning as a long term change. I was thinking
about this for other reasons - mainly performance. If I go the
partitioning route, would I need to even perform archival?
No. The idea is that you have your
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Michael Fuhr) wrote:
On Sat, Dec 17, 2005 at 09:10:40PM -0800, James Klo wrote:
I'd like some suggestions on how to get the deletes to happen faster, as
while deleting individually appears to extremely fast, when I go to
delete lots of
On Sat, 2005-12-17 at 21:10 -0800, James Klo wrote:
I need to routinely move data from the timeblock table to an archive
table with the same schema named timeblock_archive. I really need this
to happen as quickly as possible, as the archive operation appears to
really tax the db server...
On 12/18/05, James Klo [EMAIL PROTECTED] wrote:
explain analyze delete from timeblock where timeblockid = 66
Index Scan using timeblockid_idx on timeblock (cost=0.00..5.28 rows=1
width=6) (actual time=0.022..0.022 rows=0 loops=1)
Index Cond: (timeblockid = 66)
Total runtime: 0.069
Mitch Skinner wrote:
Have you considered partitioning?
http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html
If you can partition your timeblock table so that you archive an entire
partition at a time, then you can delete the archived rows by just
dropping (or truncating) that
On Sat, Dec 17, 2005 at 09:10:40PM -0800, James Klo wrote:
I'd like some suggestions on how to get the deletes to happen faster, as
while deleting individually appears to extremely fast, when I go to
delete lots of rows the operation takes an extremely long time to
complete (5000 rows takes
I have the following table:
CREATE TABLE timeblock
(
timeblockid int8 NOT NULL,
starttime timestamp,
endtime timestamp,
duration int4,
blocktypeid int8,
domain_id int8,
create_date timestamp,
revision_date timestamp,
scheduleid int8,
CONSTRAINT timeblock_pkey PRIMARY KEY
