custom cpu_tuple_cost parameter
and add the index, unless you have different suggestions.
Thank you very much so far!
Regards,
--
Silvio Moioli
SUSE Manager Development Team
y.name, rhnpackagecapability.version
Buffers: shared hit=7217
Planning time: 2.145 ms
Execution time: 358.773 ms
Is that an unreasonable value? For the sake of this discussison, I am targeting
fairly average bare-metal SSD-backed servers with recent CPUs (let's say 3 year
old maximum), with ample available RAM.
Thanks!
Regards,
--
Silvio Moioli
SUSE Manager Development Team
e is a problem in wrong estimation.
Yes, that's what I would also assume.
> What can be expected because CTE is optimization fence in this version
I am aware of that, but would not expect it to really be a problem in this
specific case. Fact that CTE is an optimization fence is true regardless of
work_mem, so ATM I cannot see why it would lead to slow down the query in high
work_mem case.
I am sure I am still missing something...
Thanks!
Regards,
--
Silvio Moioli
SUSE Manager Development Team
d why
can't the planner predict query will be slower that way?
All of the above is reproducible on openSUSE Leap and PostgreSQL 10.12.
Ideas welcome, and thanks in advance!
Regards,
--
Silvio Moioli
SUSE Manager Development Team
