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

From Tom Lane
Subject Re: sequential scan on select distinct
Date
Msg-id 29074.1097163334@sss.pgh.pa.us
Whole thread Raw
In response to Re: sequential scan on select distinct  (Pierre-Frédéric Caillaud<lists@boutiquenumerique.com>)
List pgsql-performance
=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_Caillaud?= <lists@boutiquenumerique.com> writes:
>     Present state is that DISTINCT and UNION are slow with or without using
> the GROUP BY trick. Including the index skip scan in the planning options
> would only happen when appropriate cases are detected. This detection
> would be very fast.

You have no basis whatever for making that last assertion; and since
it's the critical point, I don't intend to let you slide by without
backing it up.  I think that looking for relevant indexes would be
nontrivial; the more so in cases like you've been armwaving about just
above, where you have to find a relevant index for each of several
subqueries.  The fact that the optimization wins a lot when it wins
is agreed, but the time spent trying to apply it when it doesn't work
is a cost that has to be set against that.  I don't accept your premise
that every query for which skip-index isn't relevant is so slow that
planning time does not matter.

            regards, tom lane

pgsql-performance by date:

Previous
From: Pierre-Frédéric Caillaud
Date:
Subject: Re: sequential scan on select distinct
Next
From: Bill Montgomery
Date:
Subject: Re: Excessive context switching on SMP Xeons