On 2010-04-08 05:44, Dave Crooke wrote:
For a card level RAID controller, I am a big fan of the LSI , which is
available in a PCIe riser form factor for blade / 1U servers, and comes with
0.5GB of battery backed cache. Full Linux support including mainline kernel
drivers and command line conf
Merlin Moncure wrote:
postgresql 8.2: autovacuum enabled by default
postgresql 8.3: HOT (reduces update penalty -- zabbix does a lot of updates)
autovacuum wasn't enabled by default until 8.3. It didn't really work
all that well out of the box until the support for multiple workers was
ad
On Apr 7, 2010, at 11:13 PM, Greg Smith wrote:
> Scott Carey wrote:
>> * Change the linux 'readahead' block device parameter to at least 4MB (8192,
>> see blockdev --setra) -- I don't know if there is a FreeBSD equivalent.
>>
> I haven't tested them, but 3ware gives suggestions at
> http://www
Krzysztof Kardas wrote:
My current database variables:
That is way too much stuff to sort through. Try this instead, to only
get the values you've set to something rather than every single one:
select name,unit,current_setting(name) from pg_settings where
source='configuration file' ;
Kind of off-topic, but I've found that putting the history table on a separate
spindle (using a separate tablespace) also helps improve performance.
--Richard
On Apr 8, 2010, at 12:44 PM, Robert Haas wrote:
> 2010/4/8 Merlin Moncure :
>> previous to 8.2, to get good performance on zabbix you
2010/4/8 Merlin Moncure :
> previous to 8.2, to get good performance on zabbix you need to
> aggressively vacuum the heavily updated tables yourself.
Generally if you DON'T vacuum aggressively enough, then vacuums will
take a really long and painful amount of time, perhaps accounting for
the "hang
norn wrote:
> I have some mysterious slow downs with ORDER BY and LIMIT. When
> LIMIT getting greater than some value (greater than 3 in my case),
> query takes 4-5 secs instead of 0.25ms. All of the necessary
> indexes are in place. I have no idea what to do, so any advices
> are welcome!
Cou
On Wed Apr 7 2010 7:47 AM, Sabin Coanda wrote:
Hi there,
I have a function which returns setof record based on a specific query.
I try to check the execution plan of that query, so I write EXPLAIN ANALYZE
before my select, I call the function and I see the result which shows an
actual time about
In response to Kaloyan Iliev Iliev :
> Hi,
> Can anyone suggest why this query so slow.
>-> Index Scan using
> ms_commands_history_ms_device_id_idx on ms_commands_history ch
> (cost=0.00..4.33 rows=1 width=8) (actual time=0.163..25254.004 rows=9807
> loops=1)
Estimat
Hi Xuefeng,
You have misunderstood the problem.
The index used in the query not containing the "LIMIT 1" part, is "
index_transactions_accountid_currency", which is indeed a two column index.
The problem is this index is not used when using "LIMIT 1".
2010/4/7
>
> Guys,
>
> Thanks for try
Maybe other details about the source of the problem help.
The problem occured when I tried to optimize the specified function. It was
running in about 3 seconds, and I needed to be faster. I make some changes
and I run the well known "CREATE OR REPLACE FUNCTION ..." After that, my
function exec
On Wednesday 07 April 2010, Craig James wrote:
> I thought so too, except that I can't login during the flood. If the
> CPUs were all doing iowaits, logging in should be easy.
Busying out the drives is about the most reliable way to make logging in
very slow (especially, but not only, if it's d
Christiaan Willemsen wrote:
About a year ago we setup a machine with sixteen 15k disk spindles on
Solaris using ZFS. Now that Oracle has taken Sun, and is closing up Solaris,
we want to move away (we are more familiar with Linux anyway).
Lew wrote:
What evidence do you have that Oracle is "cl
Hi there!
I have some mysterious slow downs with ORDER BY and LIMIT. When LIMIT
getting greater than some value (greater than 3 in my case), query
takes 4-5 secs instead of 0.25ms. All of the necessary indexes are in
place. I have no idea what to do, so any advices are welcome!
Here my queries an
Hi there,
I have a function which returns setof record based on a specific query.
I try to check the execution plan of that query, so I write EXPLAIN ANALYZE
before my select, I call the function and I see the result which shows an
actual time about 5 seconds. But when I call my function after I
Actually, swapping the order of the conditions did in fact make some
difference, strange.
I ran the query a couple of times for each variation to see if the
difference in speed was just a coincidence or a pattern. Looks like the
speed really is different.
EXPLAIN ANALYZE SELECT TransactionID FROM
Sorry for the noise.
I make vacuum analyze and the problem is solved.
Kaloyan Iliev
Kaloyan Iliev Iliev wrote:
Hi,
Can anyone suggest why this query so slow.
SELECT version();
version
Hi,
Can anyone suggest why this query so slow.
SELECT version();
version
-
PostgreSQL 8.4.2 on i386-portbld-freebsd7.2, compiled by GCC cc (GCC)
2010/4/8 Grzegorz Jaśkiewicz :
> starting with 8.3, there's this new feature called HOT, which helps a lot
> when you do loads of updates.
> Plus writer is much quicker (30-40% sometimes), and autovacuum behaves much
> nicer.
> Bottom line, upgrade to 8.3, 8.1 had autovacuum disabled by default for
starting with 8.3, there's this new feature called HOT, which helps a lot
when you do loads of updates.
Plus writer is much quicker (30-40% sometimes), and autovacuum behaves much
nicer.
Bottom line, upgrade to 8.3, 8.1 had autovacuum disabled by default for a
reason.
Hi,
I am using zabbix monitoring software. The backbone database for
zabbix is postgresql 8.1 installed od linux.
Database server has 3GB of RAM, 1 CPU Dual Core and 2 SAS disks in RAID 1.
Zabbix makes a lot of inserts and updates on database. The problem is
that when autovaccum starts the datab
21 matches
Mail list logo
