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 o
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
---
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 t
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 hi
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 width
> 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 adap
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 e
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
> 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
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 righ
> Setting shared buffers above something like 10-30% of memory is counter
> productive.
What is the reason behind it being counter productive? If shared
buffers are at 30%, should effective cache size be at 70%? How do
those two relate?
>
> Increasing sort_mem can help with various activities, b
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 cas
12 matches
Mail list logo
