Thread: slower with the time

I insert data every second in my table. Every minute I delete from the
table some row to keep max 10000 rows in the table.
At the beginning deletes consume about 20% CPU time. After 24 houts
every delete needs up tu 100% CPU time (updates too).
Vacuuming doesn't help.
After I restart postmaster, it works again very quick.
Any ideas?

Thanks,
Juraj

Delete query:

 DELETE FROM tbl
WHERE time_stamp >= 0.0 AND
 time_stamp < (SELECT max(time_stamp)
                         FROM (SELECT time_stamp
                                        FROM tbl ORDER BY time_stamp,
id_event_archive ASC LIMIT 222) AS t)

PK: id_event_archive
Index: time_stamp

Postgres version: 7.3.3.
OS: Solaris 2.8

On Tuesday 01 July 2003 13:17, Juraj Porada wrote:
> I insert data every second in my table. Every minute I delete from the
> table some row to keep max 10000 rows in the table.
> At the beginning deletes consume about 20% CPU time. After 24 houts
> every delete needs up tu 100% CPU time (updates too).
> Vacuuming doesn't help.
> After I restart postmaster, it works again very quick.
> Any ideas?

Postmaster does not consume CPU for simple things like this unless it does not
have enough shared buffers.

What is your shared buffer setting? Can you tune it according to available
RAM, dataset size and type of workload?

 Shridhar

shared_buffers = 32

I don't have much experience in tuning the database, but I think there is a problem with a fragmentation of memory or so.
I don't known backgrounds.

Juraj

Shridhar Daithankar schrieb:

On Tuesday 01 July 2003 13:17, Juraj Porada wrote: 

I insert data every second in my table. Every minute I delete from the
table some row to keep max 10000 rows in the table.
At the beginning deletes consume about 20% CPU time. After 24 houts
every delete needs up tu 100% CPU time (updates too).
Vacuuming doesn't help.
After I restart postmaster, it works again very quick.
Any ideas?   

Postmaster does not consume CPU for simple things like this unless it does not 
have enough shared buffers. 

What is your shared buffer setting? Can you tune it according to available 
RAM, dataset size and type of workload?
Shridhar


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
              http://archives.postgresql.org
 

On Tuesday 01 July 2003 13:40, Juraj Porada wrote:
> shared_buffers = 32

That is 32*8=256KB of memory. I thought default was 64. How much physical
memory you have?

I suggest you set it up something like 256 to start with. That may be too
small as well but you haven't provided enough details to come up with a
better one.

>
> I don't have much experience in tuning the database, but I think there
> is a problem with a fragmentation of memory or so.
> I don't known backgrounds.

Read postgresql.conf and admin guide about runtime parameters. You need to
tune shared buffers and effective_cache_size at least.

Search performance archives about tuning these two. There is lot of material
to cover in a single mail.

 HTH

 Shridhar