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 wrote: > Robert Haas 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 i

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 wrote: > On Mon, Mar 7, 2011 at 3:40 PM, Merlin Moncure wrote: >> On Tue, Feb 22, 2011 at 9:07 PM, Robert Haas wrote: >>> On Fri, Feb 4, 2011 at 7:08 AM, Ivan Voras wrote:                                 ->  BitmapAnd  (cost=1282.94..1282.94

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

2011-03-08 Thread Tom Lane
Robert Haas 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 vs. 41 actual) > bu

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 wrote: > On Tue, Feb 22, 2011 at 9:07 PM, Robert Haas wrote: >> On Fri, Feb 4, 2011 at 7:08 AM, Ivan Voras wrote: >>>                                 ->  BitmapAnd  (cost=1282.94..1282.94 >>> rows=1430 width=0) (actual time=5.508..5.508 rows=0 loops

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 wrote: > On Fri, Feb 4, 2011 at 7:08 AM, Ivan Voras wrote: >>                                 ->  BitmapAnd  (cost=1282.94..1282.94 >> rows=1430 width=0) (actual time=5.508..5.508 rows=0 loops=1) >>                                       ->  Bitmap Inde

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 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  (cost=0.00..150.14

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 Andr

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

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. Th

[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