Re: [PERFORM] Query performance with disabled hashjoin and mergejoin

2011-03-09 Thread Robert Haas
On Tue, Mar 8, 2011 at 4:24 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: The reason I thought cross-column correlations might be relevant is that the bitmap index scan on news_visible_from is quite accurate (19976 estimated vs. 19932 actual) and the bitmap

Re: [PERFORM] Query performance with disabled hashjoin and mergejoin

2011-03-08 Thread Robert Haas
On Mon, Mar 7, 2011 at 3:40 PM, Merlin Moncure mmonc...@gmail.com wrote: On Tue, Feb 22, 2011 at 9:07 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Feb 4, 2011 at 7:08 AM, Ivan Voras ivo...@freebsd.org wrote:                                 -  BitmapAnd  (cost=1282.94..1282.94 rows=1430

Re: [PERFORM] Query performance with disabled hashjoin and mergejoin

2011-03-08 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: The reason I thought cross-column correlations might be relevant is that the bitmap index scan on news_visible_from is quite accurate (19976 estimated vs. 19932 actual) and the bitmap index scan on news_visible_to is tolerably accurate (151 estimated

Re: [PERFORM] Query performance with disabled hashjoin and mergejoin

2011-03-08 Thread Merlin Moncure
On Tue, Mar 8, 2011 at 2:57 PM, Robert Haas robertmh...@gmail.com wrote: On Mon, Mar 7, 2011 at 3:40 PM, Merlin Moncure mmonc...@gmail.com wrote: On Tue, Feb 22, 2011 at 9:07 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Feb 4, 2011 at 7:08 AM, Ivan Voras ivo...@freebsd.org wrote:      

Re: [PERFORM] Query performance with disabled hashjoin and mergejoin

2011-03-07 Thread Merlin Moncure
On Tue, Feb 22, 2011 at 9:07 PM, Robert Haas robertmh...@gmail.com wrote: On Fri, Feb 4, 2011 at 7:08 AM, Ivan Voras ivo...@freebsd.org wrote:                                 -  BitmapAnd  (cost=1282.94..1282.94 rows=1430 width=0) (actual time=5.508..5.508 rows=0 loops=1)                      

Re: [PERFORM] Query performance with disabled hashjoin and mergejoin

2011-02-22 Thread Robert Haas
On Fri, Feb 4, 2011 at 7:08 AM, Ivan Voras ivo...@freebsd.org wrote:                                 -  BitmapAnd  (cost=1282.94..1282.94 rows=1430 width=0) (actual time=5.508..5.508 rows=0 loops=1)                                       -  Bitmap Index Scan on news_index_layout_id_state  

Re: [PERFORM] Query performance with disabled hashjoin and mergejoin

2011-02-06 Thread Ivan Voras
Sorry for the misunderstaning: of course not default normal settings; shared buffers, work mem, wal segments and others have been tuned according to available hardware (e.g. 4 GB, 32 MB, 10 for these settings, respectively). I meant planner default settings in the post. -- Sent from my Android

[PERFORM] Query performance with disabled hashjoin and mergejoin

2011-02-04 Thread Ivan Voras
I'm running all this on a 9.0 server with good enough hardware. The query is: SELECT news.id AS news_id , news.layout_id , news.news_relation_id , news.author_id

Re: [PERFORM] Query performance with disabled hashjoin and mergejoin

2011-02-04 Thread Greg Smith
Ivan Voras wrote: The vanilla plan, with default settings is: Pause here for a second: why default settings? A default PostgreSQL configuration is suitable for systems with about 128MB of RAM. Since you say you have good enough hardware, I'm assuming you have a bit more than that. The

Re: [PERFORM] Query performance with disabled hashjoin and mergejoin

2011-02-04 Thread Ivan Voras
On 04/02/2011 15:44, Greg Smith wrote: Ivan Voras wrote: The vanilla plan, with default settings is: Pause here for a second: why default settings? A default PostgreSQL configuration is suitable for systems with about 128MB of RAM. Since you say you have good enough hardware, I'm assuming you