Re: add_path optimization

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: add_path optimization
Date: 2009-02-04 18:05:35
Message-ID: 4989848F.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-02-04 18:22:06 Re: patch to fix client only builds
Previous Message Svenne Krap 2009-02-04 18:04:58 Re: LIMIT NULL