Re: [PERFORM] Propagating outer join conditions

First, I forgot to mention - this is 8.2 RC1 I was trying on The suggested change produces an identical 'bad' query plan. The main issue (I think) is that the query node that processes "t1 JOIN t11 ON ..' is not aware of the join condition 't28.s = t1.s'.. even though the value of t28.s (as dete

[PERFORM] Propagating outer join conditions

The following left outer join plan puzzles me: EXPLAIN ANALYZE SELECT * from t28 LEFT OUTER JOIN (t1 JOIN t11 ON (t11.o = '' AND t11.s = t1.o)) ON t28.s = t1.s WHERE t28.o = '"spec"'; t28, t1, and t11 all have indexed columns named 's' and 'o' that contain 'text'; Nested Loo

Re: [PERFORM] Why would writes to pgsql_tmp bottleneck at 1mb/s?

> Maybe I'm not an idiot (really!) even with almost 2GB of maintenance_mem, PG > still writes to pgsql_tmp no faster than 2MB/s.I think there may be an > artificial bottleneck there. Question is, PostgreSQL, OS or hardware? I'm curious: what is your cpu usage while this is happening? I've n

Re: [PERFORM] Array types and loading

You got it.. 7.3 (should have mentioned that). We're planning to upgrade to 8.0 anyway in the future, so it's good to know. Thanks! -Aaron On Wed, 18 Aug 2004 17:39:21 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: > Aaron Birkland <[EMAIL PROTECTED]> writes: > &g

[PERFORM] Array types and loading

Hi, I noticed an interesting phenomenon when loding (COPY) some tables from a file. For some reason, one load was taking longer than I assumed it would. As it turns out, one of the columns was an array containing elements that were of a user defined type. Using strace (on linux) and truss (on