Hello Tom, good evening.
Thank you for your prompt answer and help.
It was enough to ANALYZE the temp tables to achieve a magnificent
result: 37 seconds.
I'm portuguese.
It's a shame you live so far from me. So I can't put a box of bottles of
Porto wine at your door.
I also thank David an
DiasCosta writes:
> This is the query plan for only 19684 rows.
I think you're getting a bad query plan, mostly as a result of two
factors:
* Poor row estimates. It looks like the bottom-most misestimations
are on temp tables, which makes me wonder whether you've ANALYZEd
those tables. Your ap
Hello David and Fabrízio,
The names of the tables and indexes differ from the original script.
Only the names.
This is the query plan for only 19684 rows.
I have another query running for around 3 rows, but it takes an
eternity to finish.
If it finishes in acceptable time I'll make it a
On Wed, Jun 20, 2018 at 3:34 PM, Fabrízio de Royes Mello <
fabri...@timbira.com.br> wrote:
> And use some external service like pastebin.com to send long SQL
> statements.
>
Or just attach a text file - those are allowed on these lists.
David J.
2018-06-20 18:35 GMT-03:00 DiasCosta :
>
> Hi all,
> can someone help me?
>
> I don't know if this is the correct list for this matter. If I'm wrong,
please bear with me and point me in right direction.
>
Here is a good start...
> I have a large query which, largely after more than 24 hours run
Hi all,
can someone help me?
I don't know if this is the correct list for this matter. If I'm wrong,
please bear with me and point me in right direction.
I have a large query which, largely after more than 24 hours running,
doesn't come to an end;
However I can see, using system tools, that
