Robert Haas writes:
> The alternative worth considering is presumably something like:
> GroupAggregate
> -> Index Only Scan on grue_size
> Scanning an entire index in order is pretty expensive, but it seems
> possible that this could be faster than the Seq Scan, especially on a
> table with othe
On 8 July 2016 at 09:49, Robert Haas wrote:
> We're probably missing a few tricks on queries of this type. If the
> index-traversal machinery had a mechanism to skip quickly to the next
> distinct value, that could be used here: walk up the btree until you
> find a page that contains keyspace not
On Fri, Jul 8, 2016 at 9:49 AM, Robert Haas wrote:
> On Thu, Jul 7, 2016 at 4:56 PM, Bill Moran wrote:
>> SELECT DISTINCT size FROM grue;
>>
>> Always does a seq scan on Postgres 9.5.2. (Yes, I know we're
>> a patch behind, the upgrade is on the schedule) on
>> Ubuntu 14.
>>
>> I would expect it
On Thu, Jul 7, 2016 at 4:56 PM, Bill Moran wrote:
> Take the following table as an example:
>
> CREATE TABLE grue (
> id SERIAL PRIMARY KEY,
> size VARCHAR(255)
> );
> CREATE INDEX grue_size ON grue(size);
>
> Now insert approximately eleventy jillion rows, but ensure
> that there are only about
Take the following table as an example:
CREATE TABLE grue (
id SERIAL PRIMARY KEY,
size VARCHAR(255)
);
CREATE INDEX grue_size ON grue(size);
Now insert approximately eleventy jillion rows, but ensure
that there are only about 20 distinct values for size.
SELECT DISTINCT size FROM grue;
Alwa
