Re: sequential scan on select distinct - Mailing list pgsql-performance

From Tom Lane
Subject Re: sequential scan on select distinct
Date
Msg-id 29712.1097094003@sss.pgh.pa.us
Whole thread Raw
In response to Re: sequential scan on select distinct  (Greg Stark <gsstark@mit.edu>)
List pgsql-performance
Greg Stark <gsstark@mit.edu> writes:
> But regardless of how uncommon it is, it could be considered important in
> another sense: when you need it there really isn't any alternative. It's an
> algorithmic improvement with no bound on the performance difference.

[ shrug... ]  There are an infinite number of special cases for which
that claim could be made.  The more we load down the planner with
seldom-useful special cases, the *lower* the overall performance will
be, because we'll waste cycles checking for the special cases in every
case ...

In this particular case, it's not merely a matter of the planner, either.
You'd need some new type of plan node in the executor, so there's a
pretty fair amount of added code bulk that will have to be written and
then maintained.

I'm open to being persuaded that this is worth doing, but the bar is
going to be high; I think there are a lot of other more-profitable ways
to invest our coding effort and planning cycles.

            regards, tom lane

pgsql-performance by date:

Previous
From: Doug Y
Date:
Subject: The never ending quest for clarity on shared_buffers
Next
From: Gabriele Bartolini
Date:
Subject: Data warehousing requirements