Re: add_path optimization - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: add_path optimization
Date
Msg-id 4989848F.EE98.0025.0@wicourts.gov
Whole thread Raw
In response to Re: add_path optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: add_path optimization  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Svenne Krap
Date:
Subject: Re: LIMIT NULL
Next
From: Bruce Momjian
Date:
Subject: Re: patch to fix client only builds