Re: [PERFORM] Using high speed swap to improve performance?

2010-04-06 Thread Christiaan Willemsen
Hi Scott,   That sound like a usefull thing to do, but the big advantage of the SAN is that in case the physical machine goes down, I can quickly startup a virtual machine using the same database files to act as a fallback. It will have less memory, and less CPU's but it will do fine for

Re: [PERFORM] temp table on commit delete rows: transaction overhead

2010-04-06 Thread Artiom Makarov
2010/3/30 Tom Lane t...@sss.pgh.pa.us: I don't recall any operations at transaction start for such tables, but there may be some. Both in СommitTransaction(void) and PrepareTransaction(void) we can see PreCommit_on_commit_actions() call; Here PreCommit_on_commit_actions() CUT

[PERFORM] Some question

2010-04-06 Thread Ľubomír Varga
Hi, stright to my problem: explain SELECT * FROM t_route WHERE t_route.route_type_fk = 1 limit 4; Limit (cost=0.00..0.88 rows=4 width=2640) - Seq Scan on t_route (cost=0.00..118115.25 rows=538301 width=2640) Filter: (route_type_fk = 1) If I try to select constant

Re: [PERFORM] Using high speed swap to improve performance?

2010-04-06 Thread Lew
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). What evidence do you have that Oracle is closing up

Re: [PERFORM] Does the psql executable support a fetch many approach when dumping large queries to stdout?

2010-04-06 Thread Hannu Krosing
On Fri, 2010-04-02 at 16:28 -0400, Beaver, John E wrote: ... I know that the query used here could have been a COPY statement, which I assume would be better-behaved, but I'm more concerned about the case in which the query is more complex. COPY can copy out results of a SELECT query as

Re: [PERFORM] How to fast the REINDEX

2010-04-06 Thread Hannu Krosing
On Thu, 2010-04-01 at 04:27 +0530, raghavendra t wrote: I'm sorry I couldn't come up with more, but what you've provided so far is roughly equivalent to me telling you that it takes over four hours to travel to see my Uncle Jim, and then asking you how

Re: [PERFORM] temp table on commit delete rows: transaction overhead

2010-04-06 Thread Artiom Makarov
2010/4/1 Bruce Momjian br...@momjian.us: I think one of the problems is that we do the truncate even if the table has not be touched by the query, which is poor behavior. Thank you for the support. Will be this problem registered? PS I see a workaround: switch off on commit delete rows on

[PERFORM] LIMIT causes planner to do Index Scan using a less optimal index

2010-04-06 Thread Joel Jacobson
I came across a strange problem when writing a plpgsql function. Why won't the query planner realize it would be a lot faster to use the index_transactions_accountid_currency index instead of using the transactions_pkey index in the queries below? The LIMIT 1 part of the query slows it down from

Re: [PERFORM] query slow; strace output worrisome

2010-04-06 Thread Brian Cox
On 04/06/2010 01:18 AM, Craig Ringer [cr...@postnewspapers.com.au] wrote: I'm wondering if the issue is with strace rather than Pg. That is to say, that strace is trying to print: Thanks, Craig: I do think that this is a strace issue. As for what Pg is doing: creat() returns -1 on error and a

Re: [PERFORM] 3ware vs. MegaRAID

2010-04-06 Thread Ireneusz Pluta
Greg Smith pisze: The MegaRAID SAS 84* cards have worked extremely well for me in terms of performance and features for all the systems I've seen them installed in. I'd consider it a modest upgrade from that 3ware card, speed wise. OK, sounds promising. The main issue with the MegaRAID

Re: [PERFORM] LIMIT causes planner to do Index Scan using a less optimal index

2010-04-06 Thread Robert Haas
On Fri, Apr 2, 2010 at 2:19 PM, Joel Jacobson j...@gluefinance.com wrote: Is this a bug? I'm using version 8.4.1. It's not really a bug, but it's definitely not a feature either.  Limit  (cost=0.00..43.46 rows=1 width=4) (actual time=1023.213..1023.214 rows=1 loops=1)    -  Index Scan using

Re: [PERFORM] Some question

2010-04-06 Thread Scott Marlowe
2010/3/31 Ľubomír Varga lu...@plaintext.sk: Hi, stright to my problem: If I try to select constant 1 from table with two rows, it will be something like this: explain SELECT * FROM t_route        WHERE t_route.route_type_fk = (SELECT id FROM t_route_type WHERE type = 2)        limit 4;

Re: [PERFORM] Using high speed swap to improve performance?

2010-04-06 Thread Scott Marlowe
On Sun, Apr 4, 2010 at 3:17 PM, Lew no...@lwsc.ehost-services.com wrote: 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

Re: [PERFORM] Some question

2010-04-06 Thread Kevin Grittner
*ubomír Vargalu...@plaintext.sk wrote: Hi, stright to my problem: Please show the exact problem query and the results of running it with EXPLAIN ANALYZE, along with the other information suggested here: http://wiki.postgresql.org/wiki/SlowQueryQuestions -Kevin -- Sent via

[PERFORM] indexes in partitioned tables - again

2010-04-06 Thread Samuel Gendler
I know this problem crops up all the time and I have read what I could find, but I'm still not finding an answer to my problem. This is all postgres 8.3. Yes, I've enabled constraint_exclusion. Yes, there are indexes on the partitions, not just on the parent. I've got a table with 1 month

Re: [PERFORM] LIMIT causes planner to do Index Scan using a less optimal index

2010-04-06 Thread Robert Haas
On Tue, Apr 6, 2010 at 6:30 PM, Joel Jacobson j...@gluefinance.com wrote: 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.

Re: [PERFORM] query slow; strace output worrisome

2010-04-06 Thread Craig Ringer
On 7/04/2010 12:24 AM, Brian Cox wrote: On 04/06/2010 01:18 AM, Craig Ringer [cr...@postnewspapers.com.au] wrote: I'm wondering if the issue is with strace rather than Pg. That is to say, that strace is trying to print: Thanks, Craig: I do think that this is a strace issue. As for what Pg is