Skip to main content
Question

is there a way to limit queries taking a lot of time preparing execution plan ?

  • August 7, 2017
  • 9 replies
  • 38 views

viganog
Forum|alt.badge.img+1

One of the query builder at customer site produce complex queries (with a lot of recursive SELECT). Preparation of these queries takes a lot of time (hours) and a lot of resources.

Tried to limit these queries using RUNTIMECAP or GRACEPERIOD, with no effect, because the queries are not yet "in execution" phase.

Any idea on how to limit these queries ?

Thank you !!!

gg

9 replies

TomM
Forum|alt.badge.img
  • Participating Frequently
  • August 7, 2017

viganog
Forum|alt.badge.img+1
  • Author
  • Participating Frequently
  • August 7, 2017

Hi Tom,
thank you !
but, all queries have the same behavior but are not the same (different tables, columns, analytic functions). Thinking directed queries cannot help here.
BTW, customer is trying to prevent query execution instead to run it.

Thanks you


TomM
Forum|alt.badge.img
  • Participating Frequently
  • August 7, 2017

I don't think I understand your original question. It sounds like you're building queries and that takes a long time.


viganog
Forum|alt.badge.img+1
  • Author
  • Participating Frequently
  • August 7, 2017

Exactly, the engine takes a lot of time (hours) to prepare the execution plan of the query. During this period, the query is not visible into the query_request table, and it is using a lot of system resources.


Jim_Knicely
Forum|alt.badge.img+2
  • Participating Frequently
  • August 7, 2017

Maybe lower the value of the MaxOptMemMB parameter?

dbadmin=> select parameter_name, current_value, description from configuration_parameters where parameter_name = 'MaxOptMemMB';
 parameter_name | current_value |                                                                 description
----------------+---------------+----------------------------------------------------------------------------------------------------------------------------------------------
 MaxOptMemMB    | 100           | Maximum amount of memory used by the Optimizer; Increasing this value may help with 'Optimizer memory use exceeds allowed limit' errors (MB)
(1 row)

Keep in mind this change will affect all users/queries...

A better solution might be to break up the complex SQL into smaller stages that include temp tables to hold intermediary results?


Dingqiang
Forum|alt.badge.img+1
  • Participating Frequently
  • August 9, 2017
Check catalog size, aka memory in used of METADATA resource pool in 8.0+, and try to reduce it if larger than GBs. Maybe it will help you.

viganog
Forum|alt.badge.img+1
  • Author
  • Participating Frequently
  • August 9, 2017

do you mean setting maxmemorysize for metadata resource pool < 1GB ?
Now metadata resource pool has the default setting, memorysize=0% maxmemorysize=unlimited


Dingqiang
Forum|alt.badge.img+1
  • Participating Frequently
  • August 9, 2017
No, to reduce catalog size, you'd remove unused tables/projections, reduce partitions number or ROS containers number.

Car1os
Forum|alt.badge.img
  • Participating Frequently
  • August 17, 2017

Taking hours for a plan that's is odd, sounds like something Engineering should take a look.