From: | Eduardo Morras <emorrasg(at)yahoo(dot)es> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: reducing number of ANDs speeds up query RESOLVED |
Date: | 2013-01-18 16:29:28 |
Message-ID: | 20130118172928.013d2d69cb2859189a1de594@yahoo.es |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 16 Jan 2013 23:42:23 +0100
"T. E. Lawrence" <t(dot)e(dot)lawrence(at)icloud(dot)com> wrote:
>
> On 15.01.2013, at 17:32, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> > T.E., Fortunately in point releases from August 2012 (9.0.9, 9.1.5,
> > etc.), the default server log settings will log both the cancel and
> > the command triggering the cancel. So if you are running an up to
> > date server, you can just look in the logs to see what is happening.
> >
> > Cheers,
> >
> > Jeff
>
> That's interesting, I'll check it. Thank you.
And now the million dollars question, do you have any transaction in 'IDLE IN TRANSACTION' state?
If yes, there's one possible problem. For example, we used (note the past) a message queue middleware which uses a postgres db for message passing, but it keeps the transaction in 'IDLE IN TRANSACTION' state, so if i do a select * from message_tbl i get 1-5 rows, but the tbl used (note again the past) several Gb of hd space because autovacuum couldn't clean. Of course once discovered the problem the middleware was changed by another (home-built) one which don't keeps the IDLE IN TRANSACTION state.
> T.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
--- ---
Eduardo Morras <emorrasg(at)yahoo(dot)es>
From | Date | Subject | |
---|---|---|---|
Next Message | Igor Neyman | 2013-01-18 16:37:22 | Re: speeding up a join query that utilizes a view |
Previous Message | Kirk Wythers | 2013-01-18 16:15:05 | Re: speeding up a join query that utilizes a view |