Re: [PERFORM] Performance of query

2013-03-25 Thread Cindy Makarowsky
I basically don't have any control over the generated select statement. I'm using Mondrian and that is the select statement that gets passed to Postgres. You're right that if you remove the count(id), the query is faster but I can't do that since the select statement is being executed from Mondri

Re: [PERFORM] Performance of query

2013-03-25 Thread Jeff Janes
On Sat, Mar 23, 2013 at 3:27 PM, Misa Simic wrote: > Hi Jeff, > > It seems my previous mail has not showed up in the list... copied/pasted > again belloew > > However, you said something important: > > "The join to the "state" table is not necessary. Between the foreign key > and the primary key

Re: [PERFORM] Performance of query

2013-03-23 Thread Roman Konoval
I assume there are reasons not to throw away join to state. May be it still can be done as the last thing. This should help further: SELECT counts.* FROM ( SELECT busbase.state AS state, count(busbase.id) AS m0 FROM busbase GROUP BY busbase.state ) AS counts INNER JOIN state USING (state) R

Re: [PERFORM] Performance of query

2013-03-23 Thread Misa Simic
Hi Jeff, It seems my previous mail has not showed up in the list... copied/pasted again belloew However, you said something important: "The join to the "state" table is not necessary. Between the foreign key and the primary key, you know that every state exists, and that every state exists only

Re: [PERFORM] Performance of query

2013-03-23 Thread Jeff Janes
On Friday, March 22, 2013, Cindy Makarowsky wrote: > I have two tables in Postgres 9.2 on a Linux server with 8GB of RAM. The > first table has 60 million records: You have over 40GB of data in that table, so there is no way you are going to get it into 8GB RAM without some major reorganization

Re: [PERFORM] Performance of query

2013-03-22 Thread Cindy Makarowsky
I changed the name of the table for the post but forgot to change it in the results of the explain. Table1 is busbase. On Fri, Mar 22, 2013 at 6:25 PM, Misa Simic wrote: > Hi, > > there is something mixed.. > > your index is on table1 > > Explain Analyze reports about table called: busbase.

Re: [PERFORM] Performance of query

2013-03-22 Thread Misa Simic
Hi, there is something mixed.. your index is on table1 Explain Analyze reports about table called: busbase Kind Regards, Misa 2013/3/22 Cindy Makarowsky > But, I do have an index on Table1 on the state field which is in my group > by condition: > > CREATE INDEX statidx2 > ON ta

Re: [PERFORM] Performance of query

2013-03-22 Thread Cindy Makarowsky
But, I do have an index on Table1 on the state field which is in my group by condition: CREATE INDEX statidx2 ON table1 USING btree (state COLLATE pg_catalog."default" ); I have vacuumed the table too. On Fri, Mar 22, 2013 at 5:13 PM, Josh Berkus wrote: > On 03/22/2013 12:46 PM, Cindy Mak

Re: [PERFORM] Performance of query

2013-03-22 Thread Josh Berkus
On 03/22/2013 12:46 PM, Cindy Makarowsky wrote: > I've tried playing around with the settings in the config file for > shared_buffers, work_mem, etc restarting Postgres each time and nothing > seems to help. Well, you're summarizing 55 million rows on an unindexed table: "-> Seq Scan on

[PERFORM] Performance of query

2013-03-22 Thread Cindy Makarowsky
I have two tables in Postgres 9.2 on a Linux server with 8GB of RAM. The first table has 60 million records: CREATE TABLE table1 ( id integer, update date, company character(35), address character(35), city character(20), state character(2), zip character(9), phone character(10),