Re: index problems (again) - Mailing list pgsql-general

From Geoff Winkless
Subject Re: index problems (again)
Date
Msg-id CAEzk6ffdcL+CBU8EkM3pmj5yGSfdm9mSr9NnX+E97=x1ns62nw@mail.gmail.com
Whole thread Raw
In response to Re: index problems (again)  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Responses Re: index problems (again)  ("Peter J. Holzer" <hjp-pgsql@hjp.at>)
Re: index problems (again)  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-general
On 7 March 2016 at 20:40, Peter J. Holzer <hjp-pgsql@hjp.at> wrote:
> As Tom wrote, the estimate of having to read only about 140 rows is only
> valid if sc_id and sc_date are uncorrelated. In reality your query has
> to read a lot more than 140 rows, so it is much slower.

But as I've said previously, even if I do select from scdate values
that I know to be in the first 1% of the data (supposedly the perfect
condition) the scan method is insignificantly quicker than the index
(scdate,scid) method.

Even with the absolute perfect storm (loading in the entire index for
the full range) it's still not too bad (1.3 seconds or so).

The point is that to assume, knowing nothing about the data, that the
data is in an even distribution is only a valid strategy if the worst
case (when that assumption turns out to be wildly incorrect) is not
catastrophic. That's not the case here.

Geoff


pgsql-general by date:

Previous
From: Andreas Joseph Krogh
Date:
Subject: Exclude pg_largeobject form pg_dump
Next
From: Berend Tober
Date:
Subject: Re: Logger into table and/or to cli