| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
| Cc: | David Jarvis <thangalin(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Optimize date query for large child tables: GiST or GIN? |
| Date: | 2010-05-20 13:56:50 |
| Message-ID: | 3387.1274363810@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Matthew Wakeling <matthew(at)flymine(dot)org> writes:
> On Wed, 19 May 2010, David Jarvis wrote:
>> extract( YEAR FROM m.taken ) BETWEEN 1900 AND 2009 AND
> That portion of the WHERE clause cannot use an index on m.taken. Postgres
> does not look inside functions (like extract) to see if something
> indexable is present. To get an index to work, you could create an index
> on (extract(YEAR FROM m.taken)).
What you really need to do is not do date arithmetic using text-string
operations. The planner has no intelligence about that whatsoever.
Convert the operations to something natural using real date or timestamp
types, and then look at what indexes you need.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Krzysztof Nienartowicz | 2010-05-20 14:00:03 | Query causing explosion of temp space with join involving partitioning |
| Previous Message | Matthew Wakeling | 2010-05-20 13:03:11 | Re: Optimize date query for large child tables: GiST or GIN? |