| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Pierre-Frédéric Caillaud <lists(at)boutiquenumerique(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: sequential scan on select distinct |
| Date: | 2004-10-07 15:35:34 |
| Message-ID: | 29074.1097163334@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_Caillaud?= <lists(at)boutiquenumerique(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bill Montgomery | 2004-10-07 15:48:41 | Re: Excessive context switching on SMP Xeons |
| Previous Message | Pierre-Frédéric Caillaud | 2004-10-07 12:01:13 | Re: sequential scan on select distinct |