| From: | Behrang Saeedzadeh <behrangsa(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Slow PostgreSQL 10.6 query |
| Date: | 2019-10-07 08:27:42 |
| Message-ID: | CAERAJ+_KjAJJRvXp9B-x0rY1NNzw7EgZ-MoTku3-Op8ADuDhpQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Thanks for the tip!
Regards,
Behrang (sent from my mobile)
On Mon, Oct 7, 2019, 07:37 Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
wrote:
> On Tue, Oct 01, 2019 at 11:42:33PM +1000, Behrang Saeedzadeh wrote:
> >Thanks. That eliminated the bottleneck!
> >
> >Any ideas why adding ORDER BY to the subquery also changes the plan in a
> >way that eliminates the bottleneck?
> >
>
> IIRC the ORDER BY clause makes it impossible to "collapse" the subquery
> into the main (upper) one, and it probably happens to constrict the
> choices so that the planner ends up picking a good plan. I guess adding
> "OFFSET 0" to the subquery would have the same effect.
>
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Lewis | 2019-10-07 21:53:17 | Re: distinct on extract returns composite type |
| Previous Message | Tomas Vondra | 2019-10-06 21:11:31 | Re: Out of Memory errors are frustrating as heck! |