[PERFORM] Optimize date query for large child tables: GiST or GIN?

2010-05-19 Thread David Jarvis
Hi, I recently switched to PostgreSQL from MySQL so that I can use PL/R for data analysis. The query in MySQL form (against a more complex table structure) takes ~5 seconds to run. The query in PostgreSQL I have yet to let finish, as it takes over a minute. I think I have the correct table structu

Re: [PERFORM] merge join killing performance

2010-05-19 Thread Scott Marlowe
On Wed, May 19, 2010 at 8:06 PM, Scott Marlowe wrote: > On Wed, May 19, 2010 at 8:04 PM, Scott Marlowe > wrote: >> On Wed, May 19, 2010 at 7:46 PM, Matthew Wakeling >> wrote: >>> On Wed, 19 May 2010, Scott Marlowe wrote: > > It's apparently estimating (wrongly) that the merge join won'

Re: [PERFORM] merge join killing performance

2010-05-19 Thread Scott Marlowe
On Wed, May 19, 2010 at 8:04 PM, Scott Marlowe wrote: > On Wed, May 19, 2010 at 7:46 PM, Matthew Wakeling wrote: >> On Wed, 19 May 2010, Scott Marlowe wrote: It's apparently estimating (wrongly) that the merge join won't have to scan very much of "files" before it can stop because

Re: [PERFORM] merge join killing performance

2010-05-19 Thread Scott Marlowe
On Wed, May 19, 2010 at 7:46 PM, Matthew Wakeling wrote: > On Wed, 19 May 2010, Scott Marlowe wrote: >>> >>> It's apparently estimating (wrongly) that the merge join won't have to >>> scan very much of "files" before it can stop because it finds an eid >>> value larger than any eid in the other ta

Re: [PERFORM] merge join killing performance

2010-05-19 Thread Matthew Wakeling
On Wed, 19 May 2010, Scott Marlowe wrote: It's apparently estimating (wrongly) that the merge join won't have to scan very much of "files" before it can stop because it finds an eid value larger than any eid in the other table.  So the issue here is an inexact stats value for the max eid. I wan

Re: [PERFORM] merge join killing performance

2010-05-19 Thread Scott Marlowe
On Wed, May 19, 2010 at 2:27 PM, Scott Marlowe wrote: > On Wed, May 19, 2010 at 10:53 AM, Tom Lane wrote: >> Matthew Wakeling writes: >>> On Tue, 18 May 2010, Scott Marlowe wrote: Aggregate  (cost=902.41..902.42 rows=1 width=4)     ->  Merge Join  (cost=869.97..902.40 rows=1 width=4) >

Re: [PERFORM] merge join killing performance

2010-05-19 Thread Scott Marlowe
On Wed, May 19, 2010 at 10:53 AM, Tom Lane wrote: > Matthew Wakeling writes: >> On Tue, 18 May 2010, Scott Marlowe wrote: >>> Aggregate  (cost=902.41..902.42 rows=1 width=4) >>>     ->  Merge Join  (cost=869.97..902.40 rows=1 width=4) >>>         Merge Cond: (f.eid = ev.eid) >>>         ->  Index

Re: [PERFORM] merge join killing performance

2010-05-19 Thread Scott Marlowe
On Wed, May 19, 2010 at 10:53 AM, Tom Lane wrote: > Matthew Wakeling writes: >> On Tue, 18 May 2010, Scott Marlowe wrote: >>> Aggregate  (cost=902.41..902.42 rows=1 width=4) >>>     ->  Merge Join  (cost=869.97..902.40 rows=1 width=4) >>>         Merge Cond: (f.eid = ev.eid) >>>         ->  Index

Re: [PERFORM] merge join killing performance

2010-05-19 Thread Tom Lane
Matthew Wakeling writes: > On Tue, 18 May 2010, Scott Marlowe wrote: >> Aggregate (cost=902.41..902.42 rows=1 width=4) >> -> Merge Join (cost=869.97..902.40 rows=1 width=4) >> Merge Cond: (f.eid = ev.eid) >> -> Index Scan using files_eid_idx on files f >> (cost=0.00