| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [PATCH] Equivalence Class Filters |
| Date: | 2015-12-07 18:23:47 |
| Message-ID: | CANP8+jL+f2cFP7PnTNxU-g5kf58vMS_DGyffieOax3Ycn0nb7A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 7 December 2015 at 16:55, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> Unfortunately I've seen a lot of millisecond queries that have 6 figure
> estimates, due to data being in cache. So I'm not sure how practical that
> would be.
>
We seem to be agreed that longer running queries may benefit from more
thorough optimization.
I like the idea of specifying a goal for the optimization, so the user can
explicitly ask to spend more time. But I would also rather that I didn't
have to do that at all, by using a heuristic that allows us to act sensibly
even when not explicitly instructed by the user. It Just Works.
We can decide what the heuristic limit is based upon the cost of the
technique. I don't think it matters how quick your CPU is, it matters how
long planning takes as a % of the whole expected execution time.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gavin Flower | 2015-12-07 19:27:00 | Re: [PATCH] Equivalence Class Filters |
| Previous Message | Peter Geoghegan | 2015-12-07 18:18:21 | Re: Using quicksort for every external sort run |