> That said, a look into the write-caching+BBU policy on your controller is
> worthwhile. If you're running this application successfully on some
> hardware but not others, that could be a source for the difference.
>
I think it's really a BBU/BBWC problem.
The tests that we made in the lab with
Large tables, by themselves, are not necessarily a problem. The problem is what
you might be trying to do with them. Depending on the operations you are trying
to do, partitioning the table might help performance or make it worse.
What kind of queries are you running? How many days of history a
19.07.10 18:09, Ivan Voras написав(ла):
Hello,
I don't think this is generally solvable but maybe it is so here goes.
The original situation was this:
SELECT something, big_field, complex_function(big_field), rank FROM t1
UNION ALL SELECT something, big_field, complex_function(big_field), rank
Hello,
I don't think this is generally solvable but maybe it is so here goes.
The original situation was this:
SELECT something, big_field, complex_function(big_field), rank FROM t1
UNION ALL SELECT something, big_field, complex_function(big_field), rank
from t2 ORDER BY rank LIMIT small_number;
Daniel Ferreira de Lima wrote:
> **Both with Linux Kernel 2 .4.37.9 and Postgresql 7.2**
Wow. You really need to upgrade.
Yes, but unfortunately, actually it's impossible and economically
inviable...
Generally, getting good performance out of PostgreSQL 7.2 is also
impossible
> > **Both with Linux Kernel 2 .4.37.9 and Postgresql 7.2**
>
> Wow. You really need to upgrade.
>
Yes, but unfortunately, actually it's impossible and economically
inviable...
> > Under a insertion test we get a performance of 2.5 secs under 2000
> > inserts (table with a single char(50) col
Hi,
I have a situation to handle a log table which would accumulate a
large amount of logs. This table only involves insert and query
operations. To limit the table size, I tried to split this table by
date. However, the number of the logs is still large (46 million
records per day). To further li
Daniel Ferreira de Lima wrote:
> **Both with Linux Kernel 2 .4.37.9 and Postgresql 7.2**
Wow. You really need to upgrade.
> Under a insertion test we get a performance of 2.5 secs under 2000
> inserts (table with a single char(50) column) in the IDE disk.
> And 500GB RAID 0 (4 disks!) and 3
Hi people,
I have a particular performance problem under a system installed.
In the lab I have an old Microside + Dual Core machine 1GB RAM with 40gb HD
IDE and
a newer machine HP DL 380 G5 4GB RAM and 500GB SAS under RAID 0 (4 disks)
P400i Smart Array Controller.
**Both with Linux Kernel 2 .4.3
