On Tue, Jun 13, 2023 at 10:28 PM Patrick O'Toole
wrote:
> Hi all,
>
> Questions:
>
>1. In Plan A, what factors are causing the planner to select a
>substantially slower plan despite having recent stats about number of rows?
>
> Estimated overall cost. For Plan A it is ~200k. For plans
On Wed, Jun 14, 2023 at 3:50 PM Karsten Hilbert
wrote:
> IOW neither is help to be expected on this list nor can any
> testing (on PG) help with anything to be expected on MySQL ?
>
Don't expect any help on mysql part.
As to the question: since the outer query does not have an
> ORDER BY it can
On Tue, Jun 13, 2023 at 8:55 PM Ruslan Zakirov
wrote:
> On Tue, Jun 13, 2023 at 6:06 PM Tom Lane wrote:
>
>> Ruslan Zakirov writes:
>> > I know how to fix the problem and I know that ORDER BY should be in the
>> > outermost select.
>>
>> > However
On Tue, Jun 13, 2023 at 6:06 PM Tom Lane wrote:
> Ruslan Zakirov writes:
> > I know how to fix the problem and I know that ORDER BY should be in the
> > outermost select.
>
> > However, I want to write a test case that shows that the old code is
> wrong,
> > b
On Tue, Jun 13, 2023 at 1:26 PM Thomas Kellerer wrote:
> Ruslan Zakirov schrieb am 13.06.2023 um 09:49:
> > For example I have a query:
> >
> > SELECT main.*, count(*) OVER () FROM (SELECT DISTINCT ... ORDER BY X)
> > main;
> >
> > So the `ORDER BY` cla
Hello,
For example I have a query:
SELECT main.*, count(*) OVER () FROM (SELECT DISTINCT ... ORDER BY X) main;
So the `ORDER BY` clause ended up in a subquery. Most of the time ordering
works until it doesn't.
Can you help me create a set of test tables with some data to reproduce
this problem