Re: [repost] partial index / funxtional idx or bad sql?
В списке pgsql-performance по дате отправления:
| От | Josh Berkus |
|---|---|
| Тема | Re: [repost] partial index / funxtional idx or bad sql? |
| Дата | |
| Msg-id | 200305122032.10928.josh@agliodbs.com обсуждение |
| Ответ на | Re: [repost] partial index / funxtional idx or bad sql? (csajl <csajl@yahoo.com>) |
| Ответы |
Re: [repost] partial index / funxtional idx or bad sql?
|
| Список | pgsql-performance |
Csajl, > i'm using 7.3.2. i tried using EXISTS instead of the IN, but the same > query now returns in seven sceonds as opposed to four with the IN. <snip> > classifieds_dual_idx is the btree index on (class_type_id, areacode) > and site_cm_areacode_idx is the btree index on (site_id) only. > there is an index in the areacode table that has both (site_id, areacode) > but it's apparently not being used. would it help the query to use that > index instead? No. From the look of things, it's not the index scan that's taking time ... it's the subplan, which is doing 61,000 loops. Which is normal for IN, but not for EXISTS. You run VACUUM ANALYZE? -- Josh Berkus Aglio Database Solutions San Francisco
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера