Re: [PERFORM] Unexpected query plan results

2009-06-02 Thread Robert Haas
On Tue, Jun 2, 2009 at 11:16 AM, Anne Rosset wrote: > Thanks a lot Robert. Not sure how we will tackle this but at least now we > have an explanation. From what I read, results won't improved in 8.4. Is > that correct? Yes, that's correct. Good luck... ...Robert -- Sent via pgsql-performance

Re: [PERFORM] Unexpected query plan results

2009-06-02 Thread Anne Rosset
Robert Haas wrote: On Mon, Jun 1, 2009 at 4:53 PM, Anne Rosset wrote: On Mon, Jun 1, 2009 at 2:14 PM, Anne Rosset wrote: SELECT SUM(1) FROM item WHERE is_deleted = 'f'; sum - 1824592 (1 row) SELECT SUM(1) FROM item WHERE folder_id = 'tracker3641 '; sum 122412 (1 ro

Re: [PERFORM] Best way to load test a postgresql server

2009-06-02 Thread Shaul Dar
Hi Peter, I was looking for the same recently, and my answer is as follows: 1. If you want to test the *H/W and configuration of your DBMS* then you can use the pgbench tool (which uses a specific built-in DB+schema, following the TPC benchmark). 2. If you want to *load test your own specific DB

Re: [PERFORM] Best way to load test a postgresql server

2009-06-02 Thread Kenneth Cox
On Tue, 02 Jun 2009 05:26:41 -0400, Dimitri Fontaine wrote: I'd recommand having a look at tsung which will be able to replay a typical application scenario with as many concurrent users as you want to: http://archives.postgresql.org/pgsql-admin/2008-12/msg00032.php http://tsung.erlang-pr

Re: [PERFORM] Using index for bitwise operations?

2009-06-02 Thread Matthew Wakeling
On Mon, 1 Jun 2009, Shaul Dar wrote: Our typical query select 300 "random" rows (could be located in different blocks) from the table based on another column+index, and then filters them down to ~50 based on this the bit field. So it seems that you're already using an index to fetch 300 rows f

Re: [PERFORM] Very inefficient query plan with disjunction in WHERE clause

2009-06-02 Thread Matthew Wakeling
On Mon, 1 Jun 2009, Koen Martens wrote: Anyway, any hints on getting this beast perform (without rewriting the query, that's not possible in this case due to the query being generated by an ORM) are welcome. I'm starting to think it is impossible, and that postgresql just doesn't work for this

Re: [PERFORM] Very inefficient query plan with disjunction in WHERE clause

2009-06-02 Thread Matthew Wakeling
On Mon, 1 Jun 2009, Koen Martens wrote: Anyway, any hints on getting this beast perform (without rewriting the query, that's not possible in this case due to the query being generated by an ORM) are welcome. I'm starting to think it is impossible, and that postgresql just doesn't work for this

Re: [PERFORM] Unexpected query plan results

2009-06-02 Thread Robert Haas
On Jun 2, 2009, at 6:20 AM, Віталій Тимчишин wrote: 2009/6/2 Robert Haas On Mon, Jun 1, 2009 at 4:53 PM, Anne Rosset wrote: >> On Mon, Jun 1, 2009 at 2:14 PM, Anne Rosset wrote: >>> SELECT SUM(1) FROM item WHERE is_deleted = 'f'; sum - 1824592 (1 >>> row) >>> SELECT SUM(1) F

Re: [PERFORM] Unexpected query plan results

2009-06-02 Thread Віталій Тимчишин
2009/6/2 Robert Haas > On Mon, Jun 1, 2009 at 4:53 PM, Anne Rosset wrote: > >> On Mon, Jun 1, 2009 at 2:14 PM, Anne Rosset wrote: > >>> SELECT SUM(1) FROM item WHERE is_deleted = 'f'; sum - 1824592 > (1 > >>> row) > >>> SELECT SUM(1) FROM item WHERE folder_id = 'tracker3641 > >>> '; sum

Re: [PERFORM] Best way to load test a postgresql server

2009-06-02 Thread Dimitri Fontaine
Hi, "Peter Sheats" writes: > I’m about to set up a large instance on Amazon EC2 to be our DB server. > > Before we switch to using it in production I would like to simulate some load on it so that I know what it can handle and so that I can make sure I have the > optimal settings in the conf