Re: add_path optimization
От | Kevin Grittner |
---|---|
Тема | Re: add_path optimization |
Дата | |
Msg-id | 4989848F.EE98.0025.0@wicourts.gov обсуждение исходный текст |
Ответ на | Re: add_path optimization (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: add_path optimization
|
Список | pgsql-hackers |
>>> Tom Lane <tgl@sss.pgh.pa.us> wrote: > Hmm ... one of the things that struck me as odd was that it was doing a > merge join on just the countyNo, which is presumably very far from > unique. There are 72 possible values for any columns in that domain. In most large tables, Milwaukee County (value 40) is used in about 20% of the rows. > ... using two different indexes to > accomplish the same scan, which is another weird thing about that plan). > There's no visible reason for it not to have done that Well, for a human who understand the data, I certainly would have expected it to use the primary key for both. There are never duplicate case numbers within a county, and there can certainly be a lot of cases disposed on a given date for a county. It occurred to me that this had been run with the last ANALYZE having run with a default_statistics_target of 10, but that wasn't it -- I got new statistics with a target of 100 and this part of the plan looks the same. Some other aspects of the plan changed, but if this part was the killer, a higher target doesn't help. -Kevin
В списке pgsql-hackers по дате отправления: