[PERFORM] database bloat,non removovable rows, slow query etc...

2006-09-01 Thread Matteo Sgalaberni
Hi, probably this is a very frequenfly question... I read archivies of this list but I didn't found a finally solution for this aspect. I'll explain my situation. PSQL version 8.1.3 configuration of fsm,etcc default autovacuum and statistics activated 22 daemons that have a persistent connection

Re: [PERFORM] database bloat,non removovable rows, slow query etc...

2006-09-01 Thread Matteo Sgalaberni
On Fri, Sep 01, 2006 at 10:43:30AM -0400, Tom Lane wrote: Matteo Sgalaberni [EMAIL PROTECTED] writes: 22 daemons that have a persistent connection to this database(all connection are in idle(no transaction opened). You may think that, but you are wrong. Ok. I stopped all clients

Re: [PERFORM] database bloat,non removovable rows, slow query etc... [RESOLVED]

2006-09-02 Thread Matteo Sgalaberni
On Fri, Sep 01, 2006 at 01:35:20PM -0400, Tom Lane wrote: Matteo Sgalaberni [EMAIL PROTECTED] writes: Ok. I stopped all clients. No connections to this database. When you say this database, do you mean the whole postmaster cluster, or just the one database? Open transactions in other

[PERFORM] partitioned table: differents plans, slow on some situations

2011-12-30 Thread Matteo Sgalaberni
Hi, I have a two tables that are partitioned by month. I have different results for the same query (query A/query B), the only thing that differ from A and B is the customer id. Query A: SELECT sms.id AS id_sms                                                    FROM                       

Re: [PERFORM] partitioned table: differents plans, slow on some situations

2011-12-30 Thread Matteo Sgalaberni
I'm sorry, I pasted the wrong ones, but the results are the same, here A and B again: Query A # EXPLAIN ANALYZE SELECT sms.id AS id_sms FROM sms_messaggio AS sms, sms_messaggio_dlr AS dlr WHERE sms.id =

Re: [PERFORM] partitioned table: differents plans, slow on some situations

2012-01-11 Thread Matteo Sgalaberni
- Original Message - From: Robert Haas robertmh...@gmail.com Hi Robert, I solved the problem by modifying the query: before:                    ORDER BY dlr.timestamp_todeliver DESC LIMIT after:                    ORDER BY sms.timestamp_todeliver DESC LIMIT modifying this, the