Re: [PERFORM] Database Server Tuning

2004-06-10 Thread Josh Berkus
Vivek, I did a bunch of testing with different RAID levels on a 14 disk array. I finally settled on this: RAID5 across 14 disks for the data, the OS (including syslog directory) and WAL on a RAID1 pair on the other channel of the same controller (I didn't want to spring for dual RAID

Re: [PERFORM] Scaling further up

2004-06-10 Thread Anjan Dave
Can you describe the vendors/components of a cheap SAN setup? Thanks, Anjan -Original Message- From: Rod Taylor [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 02, 2004 5:57 PM To: Scott Marlowe Cc: Anjan Dave; Chris Ruprecht; [EMAIL PROTECTED]; William Yu; Postgresql Performance

[PERFORM] Feature request: smarter use of conditional indexes

2004-06-10 Thread John Siracusa
Given an index like this: CREATE UNIQUE INDEX i1 ON t1 (c1) WHERE c1 IS NOT NULL; and a query like this: SELECT * FROM t1 WHERE c1 = 123; I'd like the planner to be smart enough to use an index scan using i1. Yes, I can change the query to this: SELECT * FROM t1 WHERE c1 = 123

Re: [PERFORM] Bulk INSERT performance in 7.4.1

2004-06-10 Thread Florian Weimer
Vivek Khera wrote: If you've got the time, could you try also doing the full bulk insert test with the checkpoint log files on another physical disk? See if that's any faster. We have been doing that for a few weeks, but the performance improvements are less than what we expected. There is

Re: [PERFORM] *very* inefficient choice made by the planner (regarding

2004-06-10 Thread Stephan Szabo
On Thu, 10 Jun 2004, Frank van Vugt wrote: Could anybody explain why the planner is doing what it is doing? What could I do to make it easier to choose a better plan? You might try raising sort_mem to see if it chooses a better plan. I think it may be guessing that the hash won't fit and

Re: [PERFORM] *very* inefficient choice made by the planner (regarding IN(...))

2004-06-10 Thread Tom Lane
Frank van Vugt [EMAIL PROTECTED] writes: What could I do to make it easier to choose a better plan? Increase sort_mem. You want it to pick a hashed subplan, but it's not doing so because 64000 rows won't fit in the default sort_mem. regards, tom lane

Re: [PERFORM] *very* inefficient choice made by the planner (regarding IN(...))

2004-06-10 Thread Frank van Vugt
Wow, The effectiveness of the pgsql mailinglists never ceases to amaze me. Default sort mem it was, I guess I'd simply been to cautious with this per-client setting. Stephan Tom : thanks! -- Best, Frank. ---(end of broadcast)---

Re: [PERFORM] Database Server Tuning

2004-06-10 Thread Anjan Dave
Vivek, Was there anything specific that helped you decide on a RAID-5 and not a RAID-10? I have my DBs on RAID10, and would soon be moving them on FC drives, and i am considering RAID-10. Thanks, Anjan -Original Message- From: Josh Berkus [mailto:[EMAIL PROTECTED]

Re: [PERFORM] *very* inefficient choice made by the planner (regarding

2004-06-10 Thread Tom Lane
Jean-Luc Lachance [EMAIL PROTECTED] writes: If the two statments are functionally equivalent, why can't PG rewrite the NOT IN version into the more efficient NOT EXISTS? They're not equivalent. In particular, the behavior in the presence of NULLs is quite different.

Re: [PERFORM] Database Server Tuning

2004-06-10 Thread Vivek Khera
On Jun 10, 2004, at 12:02 PM, Anjan Dave wrote: Vivek, Was there anything specific that helped you decide on a RAID-5 and not a RAID-10? performance testing on restore times. My DB is more than 50% write, so I needed to optimize for writes. I have my DBs on RAID10, and would soon be moving

Re: [PERFORM] *very* inefficient choice made by the planner (regarding

2004-06-10 Thread Stephan Szabo
On Thu, 10 Jun 2004, Jean-Luc Lachance wrote: I agree, but it should be a simple rewrite. No? It's NULLs inside the subselect that are the issue. select 1 in (select a from foo) select exists ( select 1 from foo where a=1) If foo.a contains a row with NULL but no rows containing a 1, the