Re: [PERFORM] How to use indexes for GROUP BY

Thanks for the trips. I'll try to first upgrade, and I'll report back if that doesn't help :) -- Dimi Paun Lattica, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

[PERFORM] How to use indexes for GROUP BY

onTS for each location. Any way I can make this more efficient? BTW, I am using postgresql-server-8.1.22-1.el5_5.1 -- Dimi Paun Lattica, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] What is postmaster doing?

R NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 23425 postgres 20 0 22008 10m 10m R 99.9 0.5 21:45.87 postmaster -- Dimi Paun Lattica, Inc. -- Sent via pgsql-per

Re: [PERFORM] What is postmaster doing?

. I'm running CentOS 5.5, using procps-3.2.7-16.el5. I cannot check more at this point as postmaster seems to have finished whatever it was doing, but I'll try to investigate better next time. -- Dimi Paun Lattica, Inc. -- Sent via pgsql-performance mailing list (pgsq

Re: [PERFORM] What is postmaster doing?

be doing what I need. Too bad I couldn't figure out what was going on when I was experiencing the high load, but now that I have the logging enabled, it shouldn't be a problem to figure things out. -- Dimi Paun Lattica, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance

[PERFORM] What is postmaster doing?

there a way I can log all SQL statements to a file, together with the time it took to execute them? -- Dimi Paun Lattica, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] DISTINCT vs. GROUP BY

= 'CPC-RMA-00110'::text) Total runtime: 0.151 ms (6 rows) For now we are stuck with 8.1, so the easiest fix for us is to use GROUP BY. Since this is fixed in later versions, I guess there's not much to see here... :) Thanks for the quick reply! -- Dimi Paun Lattica, Inc. --

[PERFORM] DISTINCT vs. GROUP BY

ntrmainid)::text = 'CPC-RMA-00109'::text) Total runtime: 73.144 ms What gives? -- Dimi Paun Lattica, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Bad performance on simple query

t (local vs remote) in psql (0.668ms vs. 0.760ms). More like it. WTH is pgadminIII reporting?!? -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Bad performance on simple query

20ms 0.091ms How now I try to replicate, and I get 45ms in both cases. This is very misleading... -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Bad performance on simple query

I reports the query taking 20-40ms, so I read the 0.091 as seconds not ms. -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

[PERFORM] Bad performance on simple query

This is not a fast machine, but this seems rather excessive, no? -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Severe performance problems for simple query

t manner (seq scan on an indexed table for a BETWEEN filter doesn't qualify :)). Many thanks! -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Severe performance problems for simple query

width=145) (actual time=1245.290..1245.290 rows=1 loops=1) Filter: ((ipfrom <= 2130706433) AND (2130706433 <= ipto) AND (ipto > ipfrom)) Total runtime: 1245.335 ms (4 rows) > I don't know why the single index lookup took > 300ms, though. That > does seem high to me. T

[PERFORM] Severe performance problems for simple query

null, countyName varchar(255) not null, latitude float8 not null, longitude float8 not null, createdTS timestamp with time zone default current_timestamp, primary key(ipFrom, ipTo) ); -- Dimi Paun <[EMAIL PROTECTED]> Lattica, Inc. -- Sent via pgsql-performance mailing list (p