Re: Increasing work_mem slows down query, why? - Mailing list pgsql-performance

From Tom Lane
Subject Re: Increasing work_mem slows down query, why?
Date
Msg-id 19893.1585586177@sss.pgh.pa.us
Whole thread Raw
In response to Re: Increasing work_mem slows down query, why?  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Increasing work_mem slows down query, why?  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-performance
Pavel Stehule <pavel.stehule@gmail.com> writes:
> CTE scan has only 1100 rows, public.rhnpackagecapability  has 490964 rows.
> But planner does hash from public.rhnpackagecapability table. It cannot be
> very effective.

[ shrug... ]  Without stats on the CTE output, the planner is very
leery of putting it on the inside of a hash join.  The CTE might
produce output that ends up in just a few hash buckets, degrading
the join to something not much better than a nested loop.  As long
as there's enough memory to hash the known-well-distributed table,
putting it on the inside is safer and no costlier.

            regards, tom lane



pgsql-performance by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Increasing work_mem slows down query, why?
Next
From: Pavel Stehule
Date:
Subject: Re: Increasing work_mem slows down query, why?