Hi,
I'm using a workaround for this kind of issues:
consider:
select A from
(select B from T1 where C
union
select B from T2 where C
union
select B from T3 where C
) foo
where D
in your
On 5/26/05, Christopher Kings-Lynne [EMAIL PROTECTED] wrote:
I have some queries that have significan't slowed down in the last
couple days. It's gone from 10 seconds to over 2 mins.
The cpu has never gone over 35% in the servers lifetime, but the load
average is over 8.0 right now. I'm
Few mandatory questions:
1. Do you vacuum your db on regular basis? :)
It's vacuumed once every hour. The table sizes and data are constantly changing.
2. Perhaps statistics for tables in question are out of date, did you
try alter table set statistics?
No I haven't. What would that
Hi @ all,
i'm trying to tune my postgresql-db but i don't know if the values are right
set.
I use the following environment for the postgres-db:
# Hardware
cpu: 2x P4 3Ghz
ram: 1024MB DDR 266Mhz
partitions:
/dev/sda3 23G 9,6G 13G 44% /
/dev/sda1 11G 156M 9,9G 2%
Josh Close [EMAIL PROTECTED] writes:
this_sQuery := \'
SELECT COALESCE( SUM( iNumSent ), 0 ) AS iNumSent
FROM adaption.tblBatchHistory_\' || this_rServerIds.iId || \'
WHERE tStamp now() - interval \'\'5 mins\'\';
\';
Here is the explain
I think you really want that seqscan to be an indexscan, instead.
I'm betting this is PG 7.4.something? If so, probably the only
way to make it happen is to simplify the now() expression to a constant:
SELECT COALESCE( SUM( iNumSent ), 0 ) AS iNumSent
FROM
Doing the query
explain
SELECT COALESCE( SUM( iNumSent ), 0 ) AS iNumSent
FROM adaption.tblBatchHistory_1
WHERE tStamp ( now() - interval '5 mins' )::text
gives me this:
Aggregate (cost=32138.33..32138.33 rows=1 width=4)
- Seq Scan on tblbatchhistory_1 (cost=0.00..31996.10 rows=56891
What are the effect of having a table with arround 500 insert/update/delete on
two to eight table in a time frame of 2 minutes 24/24h, when you have oid
enabled versus the same setup when you dont have oid?
That deployment is done on a postgres with 8 to 9 databases, each having those
2 to 8
Would I be correct in assuming that the following two indexes are
completely redundant except for the fact that one complains about
uniqueness constraint violations and the other does not?
Or is there are legitimate use for having BOTH indexes?
I'm trying to figure out if it's okay to delete
Jeffrey Tenny [EMAIL PROTECTED] writes:
Would I be correct in assuming that the following two indexes are
completely redundant except for the fact that one complains about
uniqueness constraint violations and the other does not?
Yup ...
regards, tom lane
On Fri, 2005-05-27 at 13:05 -0400, Eric Lauzon wrote:
What are the effect of having a table with arround 500
insert/update/delete on two to eight table in a time frame of 2
minutes 24/24h, when you have oid enabled versus the same setup when
you dont have oid?
That deployment is done on a
11 matches
Mail list logo
