From: | Marco Renzi <renzi(dot)mrc(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Query with no result set, really really slow adding ORBDER BY / LIMIT clause |
Date: | 2017-04-21 07:05:36 |
Message-ID: | CAHmtSMZ1+s4voZidJdF92uVQgY+XOMe3THQo9p5XFpb4HwzXNA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>
> I am thinking so limit 10000 should be ok. Too big number can be messy for
> optimizer similarly like too small number.
>
> The planner is driven by statistics - and the statistics are not perfect -
> usually it is working on 80% - like weather forecasting.
>
> Usually it is working, but sometimes not.
>
> Regards
>
> Pavel
>
>
>
Thanks Pavel, i almost found two solutions at the end:
One is to use an inner limit as you said, and the other, when you just know
what the filter is,
is to try to join with SELECTS that have to be executed first from the
planner.
Eg
SELECT fase.id
FROM tipofase
JOIN fase
ON (fase.tipofase = (SELECT tipofase.id FROM tipofase WHERE
tipofase.agendafrontoffice = true))
ORDER BY fase.id DESC limit 10 offset 0
Thanks for the help
--
-------------------------------------------------------------------------------------------------------------------------------------------
Ing. Marco Renzi
OCA - Oracle Certified Associate Java SE7 Programmer
OCP - Oracle Certified Mysql 5 Developer
via Zegalara 57
62014 Corridonia(MC)
Mob: 3208377271
"The fastest way to change yourself is to hang out with people who are
already the way you want to be" Reid Hoffman
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2017-04-21 07:12:53 | Re: Query with no result set, really really slow adding ORBDER BY / LIMIT clause |
Previous Message | Pavel Stehule | 2017-04-21 06:56:17 | Re: Query with no result set, really really slow adding ORBDER BY / LIMIT clause |