We had problems again, caused by long running transactions. I'm
monitoring the pg_stat_activity view, checking the query_start of all
requests that are not idle - but this one slipped under the radar as the
application was running frequent queries towards the database.
That's not what concerns me
Hi,
On Tue, 2007-04-10 at 22:55 +0200, Guillaume Smet wrote:
> See http://developer.postgresql.org/~devrim/rpms/compat/ and choose
> the correct package for your architecture.
... or better, each RHEL4 directory in our FTP site has compat package
(that directory is not up2date now).
Regards,
--
On 4/10/07, Michael Dengler <[EMAIL PROTECTED]> wrote:
I'm using RHEL4 and wondering if I need to upgrade the php and php-pgsql
packages when upgrading from Postgres 7.4.1 to 8.2.3.
No you don't. Devrim Gunduz provides compat RPM for a long time now.
See http://developer.postgresql.org/~devrim
Hi,
I'm using RHEL4 and wondering if I need to upgrade the php and php-pgsql
packages when upgrading from Postgres 7.4.1 to 8.2.3.
Any Help?
Thanks
Mike
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> right, i see that it's actually the 'group by' that does it:
> select a, b from foo join (select a, b from bar group by a,b) q using (a,b);
> is enough to keep it from using the index on a,b from bar. thats too bad...
Some day it'd be nice to be able
On 4/10/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> For some reason, I can't get the index to be used on the table sitting
> under a view during a join, even though it should be, or at least it
> seems
Nope, that's not going to work, because the agg
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> For some reason, I can't get the index to be used on the table sitting
> under a view during a join, even though it should be, or at least it
> seems
Nope, that's not going to work, because the aggregate keeps the subquery
from being flattened int
"Spiegelberg, Greg" <[EMAIL PROTECTED]> writes:
> Below is, I believe, everything pertinent to this problem. First is the
> table in question, second is the problematic and original query, and
> final is the transaction that I have working today with the CTID
> implementation.
So the basic issue
Yeah, I have a lot of similar problems where an index that I have to
speed up one query is used in another query where it actually slows
it down. Is there any way to ignore indexes for certain queries?
We've been appending empty strings and adding zero's to the column
data to force it int
Drew Wilson <[EMAIL PROTECTED]> writes:
> If I understand the EXPLAIN ANALYZE results below, it looks like the
> time spent applying the "set is_public = true" is much much more than
> the fetch. I don't see any triggers firing.
Nope, there aren't any. 8.2 is smart enough to bypass firing FK
On Apr 10, 2007, at 6:54 AM, Tom Lane wrote:
Drew Wilson <[EMAIL PROTECTED]> writes:
The SELECT is not slow, so its a side effect of the update... Looking
at the table definition, there is a "BEFORE ON DELETE" trigger
defined, two CHECK constraints for this table, and three foreign
keys. Nothi
In your first post you said that the query is taking much longer than a
second, and in your second post you say the performance is horrible, but
explain analyze shows the query runs in 219 milliseconds, which doesn't seem
too bad to me. I wonder if the slow part for you is returning all the rows
t
Drew Wilson <[EMAIL PROTECTED]> writes:
> The SELECT is not slow, so its a side effect of the update... Looking
> at the table definition, there is a "BEFORE ON DELETE" trigger
> defined, two CHECK constraints for this table, and three foreign
> keys. Nothing looks suspicious to me.
Since th
Craig,
I'm not using a TEMP TABLE in this DELETE however I have tried an
ANALYZE prior to the DELETE but it hardly makes a dent in the time.
Please look at the other follow-up email I just sent for full details.
Greg
-Original Message-
From: Craig A. James [mailto:[EMAIL PROTECTED]
S
Tom et al,
Sometimes it takes a look from someone on the outside to get the job
done right.
Below is, I believe, everything pertinent to this problem. First is the
table in question, second is the problematic and original query, and
final is the transaction that I have working today with the CTI
On 4/9/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
On 4/9/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > I have an odd performance issue on 8.2 that I'd thought I'd document
> > here. I have a workaround, but I'm if there is something that I'm not
>
16 matches
Mail list logo
