On 3/30/20 6:02 PM, Tom Lane wrote:
> Yeah, the run time of the slow query seems to be almost entirely expended
> in these two sort steps, while the planner doesn't think that they'll be
> very expensive. Tweaking unrelated cost settings to work around that is
> not going to be helpful. What you'
Justin thank you very much for your answer, as you can also see the number of
rows differs a lot
I attach the complete explain, do not attach it because it is large
"HashAggregate (cost=12640757.46..12713163.46 rows=385 width=720) (actual
time=1971962.023..1971962.155 rows=306 loops=1)"
" Output
On Fri, Apr 03, 2020 at 09:03:49AM -0700, dangal wrote:
> Dear I have a question to ask you
> I am having a slow problem with a query and I am seeing with the explain that
> the current cost and time differ by 4 times
The "cost" is in arbitrary units, and the time is in units of milliseconds.
The
Dear I have a question to ask you
I am having a slow problem with a query and I am seeing with the explain
that the current cost and time differ by 4 times
Postgres version 9.5.16 in centos 7.6
To try to solve this run the statistics to the table and the same problem
remains
It's a very big table 2
