Re: Optimize date query for large child tables: GiST or GIN?
В списке pgsql-performance по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Optimize date query for large child tables: GiST or GIN? |
| Дата | |
| Msg-id | 3387.1274363810@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Optimize date query for large child tables: GiST or GIN? (Matthew Wakeling <matthew@flymine.org>) |
| Ответы |
Re: Optimize date query for large child tables: GiST or
GIN?
|
| Список | pgsql-performance |
Matthew Wakeling <matthew@flymine.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
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера