On Sat, 2005-11-19 at 06:29, Alex Wang wrote:
> Great infomation. I didn't know that update is equal to delete+insert in
> Postgres. I would be more careful on designing the database access method in
> this case.
Just make sure you have regular vacuums scheduled (or run them from
within your app
t;[EMAIL PROTECTED]>
Cc: "postgres performance list"
Sent: Saturday, November 19, 2005 8:12 PM
Subject: Re: [PERFORM] VERY slow after many updates
Just for clarification, update is actually equal to delete+insert in
Postgres. So if you update rows, it's the same as you would d
On 19.11.2005, at 13:05 Uhr, Alex Wang wrote:
Yes, it's a "queue" table. But I did not perform many insert/delete
before it becomes slow. After insert 10 records, I just do get/
update continuously.
When PostgreSQL updates a row, it creates a new row with the updated
values. So you should
ecords.
>
> Thanks,
> Alex
>
> - Original Message -
> From: "Csaba Nagy" <[EMAIL PROTECTED]>
> To: "Alex Wang" <[EMAIL PROTECTED]>
> Cc: "postgres performance list"
> Sent: Saturday, November 19, 2005 7:12 PM
> S
e are only 100 records.
Thanks,
Alex
- Original Message -
From: "Csaba Nagy" <[EMAIL PROTECTED]>
To: "Alex Wang" <[EMAIL PROTECTED]>
Cc: "postgres performance list"
Sent: Saturday, November 19, 2005 7:12 PM
Subject: Re: [PERFORM] VERY slow after
Alex,
I suppose the table is a kind of 'queue' table, where you
insert/get/delete continuously, and the life of the records is short.
Considering that in postgres a delete will still leave you the record in
the table's file and in the indexes, just mark it as dead, your table's
actual size can gro
