Re: [PERFORM] Optimizing query

2010-11-26 Thread Pierre C
Note that your LEFT JOIN condition is probably quite slow... Please post EXPLAIN ANALYZE for this simplified version : SELECT R."Osoba weryfikuj?ca", R."LP", A."NKA", A."NTA", Sum("Ile") FROM"NumeryA" A LEFT JOIN "Rejestr stacji do napr

Re: [PERFORM] Which gives good performance? separate database vs separate schema

2010-11-26 Thread Robert Klemme
On Thu, Nov 25, 2010 at 4:46 PM, wrote: >> I am not facing any issues, but yes I want to have optimal performance for >> SELECT and INSERT, especially when I am doing these ops repeatedly. >> Actually I am porting from Oracle to PG. Oracle starts a lot of processes >> when >> it needs to run many

[PERFORM] Update problem on large table

2010-11-26 Thread felix
Hello, I have a very large table that I'm not too fond of. I'm revising the design now. Up until now its been insert only, storing tracking codes from incoming webtraffic. It has 8m rows It appears to insert fine, but simple updates using psql are hanging. update ONLY traffic_tracking2010 set s

Re: [PERFORM] Optimizing query

2010-11-26 Thread pasman pasmański
Thanks for reply. First query: SELECT R."Osoba weryfikująca" AS "Osoba", R."LP"::text AS "Sprawa", A."NKA", A."NTA", Sum(A."Ile")::text AS "Ilość CDR" FROM ONLY "NumeryA" A LEFT JOIN "Rejestr stacji do naprawy" R ON A."NKA" = R."Numer kierunkowy" and A."NTA" like R."Numer stacji" and

Re: [PERFORM] Update problem on large table

2010-11-26 Thread bricklen
On Fri, Nov 26, 2010 at 6:22 AM, felix wrote: > > Hello, > I have a very large table that I'm not too fond of.  I'm revising the design > now. > Up until now its been insert only, storing tracking codes from incoming > webtraffic. > It has 8m rows > It appears to insert fine, but simple updates us

Re: [PERFORM] CPUs for new databases

2010-11-26 Thread Christian Elmerot @ One.com
On 2010-10-27 21:58, Greg Smith wrote: Ivan Voras wrote: FWIW, yes - once the IO is fast enough or not necessary (e.g. the read-mostly database fits in RAM), RAM bandwidth *is* the next bottleneck and it really, really can be observed in actual loads. This is exactly what I've concluded, afte

Re: [PERFORM] CPUs for new databases

2010-11-26 Thread Kevin Grittner
"Christian Elmerot @ One.com" wrote: > Highest results comes at 32 threads: It would be interesting to see the results if you built a version of PostgreSQL with LOG2_NUM_LOCK_PARTITIONS set to 6 (instead of 4). -Kevin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresq

Re: [PERFORM] CPUs for new databases

2010-11-26 Thread Greg Smith
Christian Elmerot @ One.com wrote: Highest results comes at 32 threads: Number of Threads requested = 32 Function Rate (MB/s) Avg time Min time Max time Triad: 81013.5506 0.0378 0.0377 0.0379 There is some run-to-run variation in the results of this test, a