Re: Optimize date query for large child tables: GiST or GIN?
Вложения
В списке pgsql-performance по дате отправления:
| От | Stephen Frost |
|---|---|
| Тема | Re: Optimize date query for large child tables: GiST or GIN? |
| Дата | |
| Msg-id | 20100520213029.GQ21875@tamriel.snowman.net обсуждение исходный текст |
| Ответ на | Re: Optimize date query for large child tables: GiST or GIN? (David Jarvis <thangalin@gmail.com>) |
| Ответы |
Re: Optimize date query for large child tables: GiST or
GIN?
|
| Список | pgsql-performance |
* David Jarvis (thangalin@gmail.com) wrote:
> I was still referring to the measurement table. You have an index on
> > stationid, but still seem to be getting a sequential scan. Maybe the planner
> > does not realise that you are selecting a small number of stations. Posting
> > an EXPLAIN ANALYSE would really help here.
> >
>
> Here is the result from an *EXPLAIN ANALYZE*:
Yeah.. this is a horrible, horrible plan. It does look like you've got
some serious data tho, at least. Basically, PG is sequentially scanning
through all of the tables in your partitioning setup. What is
constraint_exclusion set to? What version of PG is this? Do the
results og this query look at all correct to you?
Have you considered an index on elevation, btw? How many records in
that city table are there and how many are actually in that range?
Thanks,
Stephen
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера