On 10/09/13 20:04, David Whittaker wrote:
On Tue, Sep 10, 2013 at 11:26 AM, Andrew Dunstan and...@dunslane.net
mailto:and...@dunslane.net wrote:
On 09/10/2013 11:04 AM, David Whittaker wrote:
Hi All,
I've been seeing a strange issue with our Postgres install for
On Tue, Sep 10, 2013 at 02:04:57PM -0400, David Whittaker wrote:
Hi Andrew,
On Tue, Sep 10, 2013 at 11:26 AM, Andrew Dunstan and...@dunslane.netwrote:
On 09/10/2013 11:04 AM, David Whittaker wrote:
Hi All,
I've been seeing a strange issue with our Postgres install for about a
Hi there,
here is another one from the why is my query so slow? category. First post,
so please bare with me.
The query (which takes around 6 seconds) is this:
SET work_mem TO '256MB';//else sort spills to disk
SELECT
et.subject,
COALESCE (createperson.vorname || ' ', '') ||
Hi all,
I have a number of Postgres 9.2.4 databases with the same schema but with
slightly different contents, running on small servers that are basically
alike (8-16 GB ram).
When I run the same query on these databases it results in one of two
different execution plans where one is much faster
On Tue, Sep 10, 2013 at 10:04 AM, David Whittaker d...@iradix.com wrote:
Hi All,
I've been seeing a strange issue with our Postgres install for about a year
now, and I was hoping someone might be able to help point me at the cause.
At what seem like fairly random intervals Postgres will
On Wed, Sep 11, 2013 at 3:36 AM, Maximilian Tyrtania
li...@contactking.dewrote:
JOIN emailsendings es ON et. ID = es.emailtemplate_id
ORDER BY
es.sentonat desc
Perhaps on an index on (es.emailtemplate_id, es.sentonat desc) would help?
Thanks, unfortunately it (creating that index) didn't. But I rewrote my query
using inline subqueries, which already helped a lot.
Thanks again,
Maximilian Tyrtania
http://www.contactking.de
Am 11.09.2013 um 15:58 schrieb bricklen brick...@gmail.com:
On Wed, Sep 11, 2013 at 3:36 AM,
On 09/11/2013 06:36 AM, Maximilian Tyrtania wrote:
Hi there,
here is another one from the why is my query so slow? category. First post,
so please bare with me.
The query (which takes around 6 seconds) is this:
SET work_mem TO '256MB';//else sort spills to disk
SELECT
et.subject,
On Wed, Sep 11, 2013 at 4:16 AM, Mikkel Lauritsen ren...@tala.dk wrote:
Hi all,
I have a number of Postgres 9.2.4 databases with the same schema but with
slightly different contents, running on small servers that are basically
alike (8-16 GB ram).
When I run the same query on these
Il 11/09/2013 13:16, Mikkel Lauritsen ha scritto:
Hi all,
I have a number of Postgres 9.2.4 databases with the same schema but with
slightly different contents, running on small servers that are basically
alike (8-16 GB ram).
I think that your answer can be found in your statement slightly
On 2013-09-11 07:43:35 -0500, Merlin Moncure wrote:
I've been seeing a strange issue with our Postgres install for about a year
now, and I was hoping someone might be able to help point me at the cause.
At what seem like fairly random intervals Postgres will become unresponsive
to the 3
On Wed, Sep 11, 2013 at 12:17 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-11 07:43:35 -0500, Merlin Moncure wrote:
I've been seeing a strange issue with our Postgres install for about a year
now, and I was hoping someone might be able to help point me at the cause.
At what
All,
We've confirmed that this issue is caused by having long-running idle
transactions on the server. When we disabled their queueing system
(which prodiced hour-long idle txns), the progressive slowness went away.
Why that should affect 9.X far more strongly than 8.4, I'm not sure
about.
On 09/11/2013 02:35 PM, Josh Berkus wrote:
All,
We've confirmed that this issue is caused by having long-running idle
transactions on the server. When we disabled their queueing system
(which prodiced hour-long idle txns), the progressive slowness went away.
Why that should affect 9.X far
Hi all,
On Wed, 11 Sep 2013 18:55:38 +0200, Giuseppe Broccolo
giuseppe.brocc...@2ndquadrant.it wrote:
Il 11/09/2013 13:16, Mikkel Lauritsen ha scritto:
Hi all,
I have a number of Postgres 9.2.4 databases with the same schema but
with slightly different contents, running on small servers
On 2013-09-11 15:06:23 -0400, Andrew Dunstan wrote:
On 09/11/2013 02:35 PM, Josh Berkus wrote:
All,
We've confirmed that this issue is caused by having long-running idle
transactions on the server. When we disabled their queueing system
(which prodiced hour-long idle txns), the
On 12/09/13 04:55, Giuseppe Broccolo wrote:
Il 11/09/2013 13:16, Mikkel Lauritsen ha scritto:
Hi all,
I have a number of Postgres 9.2.4 databases with the same schema but
with
slightly different contents, running on small servers that are basically
alike (8-16 GB ram).
I think that your
On 2013-09-11 11:35:45 -0700, Josh Berkus wrote:
All,
We've confirmed that this issue is caused by having long-running idle
transactions on the server. When we disabled their queueing system
(which prodiced hour-long idle txns), the progressive slowness went away.
Why that should affect
The explanation is in
http://archives.postgresql.org/message-id/20130910132133.GJ1024477%40alap2.anarazel.de
The referenced commit introduced a planner feature. Funnily you seem to
have been the trigger for it's introduction ;)
Oh, crap, the off the end of the index optimization?
It's the
19 matches
Mail list logo
