Kenneth Marshall wrote:
> I think this is it:
>
>
http://archives.postgresql.org/pgsql-committers/2010-01/msg00021.php
Looks like it. Based on the commit date, that would be a 9.0
change. Based on the description, I'm not sure it fixes Derrick's
problem; the workaround of explicitly using m
"Kevin Grittner" writes:
> Derrick Rice wrote:
>> Kevin Grittner >> there is a feature to probe the end of an index's range in
>>> situations where data skew was often causing less than optimal
>>> plans to be chosen.
>> Was this introduced in 9.0 or was it earlier?
> I don't remember when it
On Thu, Mar 17, 2011 at 09:49:45AM -0500, Kevin Grittner wrote:
> Derrick Rice wrote:
> > Kevin Grittner >
> >> there is a feature to probe the end of an index's range in
> >> situations where data skew was often causing less than optimal
> >> plans to be chosen.
> >
> > Was this introduced in
Derrick Rice wrote:
> Kevin Grittner
>> there is a feature to probe the end of an index's range in
>> situations where data skew was often causing less than optimal
>> plans to be chosen.
>
> Was this introduced in 9.0 or was it earlier?
I don't remember when it was added. I took a stab at s
On Wed, Mar 16, 2011 at 5:56 PM, Kevin Grittner wrote:
> there is a feature to probe the end of an index's range in
> situations where data skew was often causing less than optimal plans
> to be chosen.
>
Was this introduced in 9.0 or was it earlier? My company hasn't introduced
integrated supp
Derrick Rice wrote:
> I recently ran into a problem with a planner opting for a
> sequential scan rather than a bitmap heap scan because the stats
> suggested that my delete query was going to affect 33% of the
> rows, rather than the 1% it really was.
> could possibly react by updating the hi
Oh, I'm using 8.2
On Wed, Mar 16, 2011 at 3:40 PM, Derrick Rice wrote:
> Greetings.
>
> I recently ran into a problem with a planner opting for a sequential scan
> rather than a bitmap heap scan because the stats suggested that my delete
> query was going to affect 33% of the rows, rather than th
Greetings.
I recently ran into a problem with a planner opting for a sequential scan
rather than a bitmap heap scan because the stats suggested that my delete
query was going to affect 33% of the rows, rather than the 1% it really
was. I was able to follow the planner's logic and came to the real
