Postgres GEQO ¤Ë¤ª¤± ¤ëº£¸å¤Î¼ÂÁõºî¶È

´ðËÜŪ¤Ê²þÁ±

Ì䤤¹ç¤ï¤»½èÍý´°Î»»þ¤Î¥á¥â¥ê³«Êü¤Ë¤Ä¤¤¤Æ¤Î²þÁ±

With large join queries the computing time spent for the genetic query optimization seems to be a mere fraction of the time Postgres needs for freeing memory via routine MemoryContextFree, file backend/utils/mmgr/mcxt.c. Debugging showed that it get stucked in a loop of routine OrderedElemPop, file backend/utils/mmgr/oset.c. The same problems arise with long queries when using the normal Postgres query optimization algorithm.

Â絬ÌÏ join Ì䤤¹ç¤ï¤»¤ÎºÝ¤Ë¡¢°äÅÁŪÌ䤤¹ç¤ï¤»ºÇ Ŭ²½¤Ç»È¤ï¤ì¤ë±é»»»þ´Ö¤Ï¡¢ backend/utils/mmgr/mcxt.c ¥Õ¥¡¥¤¥ë¤Î MemoryContextFree ½èÍý¤ò»È¤Ã¤Æ Postgres ¤¬¥á¥â¥ê³«Êü¤ò¹Ô¤Ê¤¦»þ¤ËɬÍפȤ¹ ¤ë»þ´Ö¤Î ¤´¤¯°ìÉô ¤Ë²á¤®¤Ê¤¤¤è¤¦¤Ç¤¹¡£¥Ç¥Ð¥Ã¥° ¤·¤Æ¤ß¤ë¤È¡¢backend/utils/mmgr/oset.c ¥Õ¥¡¥¤¥ë ¤Î OrderedElemPop ½èÍýÆâ¤Î¥ë¡¼¥×¤Ç»þ´Ö¤¬¤«¤«¤Ã ¤Æ¤¤¤Þ¤·¤¿¡£Æ±¤¸ÌäÂê¤ÏÄ̾ï¤Î Postgres Ì䤤¹ç¤ï¤»ºÇŬ²½¥¢¥ë¥´¥ê¥º¥à¤ò»È¤Ã¤ÆŤ¤Ì䤤¹ç¤ï¤»¤ò¹Ô¤Ê¤Ã¤¿»þ¤Ë¤âȯ À¸¤·¤Þ¤¹¡£

°äÅÁŪ¥¢¥ë¥´¥ê¥º¥à¤Î¥Ñ¥é¥á¡¼¥¿ÀßÄê¤Ë¤Ä¤¤¤Æ¤Î²þÁ±

In file backend/optimizer/geqo/geqo_params.c, routines gimme_pool_size and gimme_number_generations, we have to find a compromise for the parameter settings to satisfy two competing demands:

backend/optimizer/geqo/geqo_params.c ¥Õ¥¡¥¤¥ë¤Î gimme_pool_size ½èÍý¤È gimme_number_generations ½èÍý¤Ë¤ª¤¤¤Æ¡¢¼¡¤Î 2 ¤Ä ¤ÎÁêÈ¿¤¹¤ëÍ×µá¤ò¤ß¤¿¤¹¤è¤¦¤Ê¥Ñ¥é¥á¡¼¥¿ÀßÄê¤ÎÂŶ¨ÅÀ¤ò¸«¤Ä¤±¤Ê¤±¤ì¤Ð¤¤¤± ¤Þ¤»¤ó¡£

  • Optimality of the query plan

    Ì䤤¹ç¤ï¤»·×²è¤ÎºÇŬÀ­

  • Computing time

    ·×»»»þ´Ö

À°¿ô¥ª¡¼¥Ð¡¼¥Õ¥í¡¼¤Ë¤Ä¤¤¤Æ¤è¤ê¤è¤¤²ò·èºö¤Îõµá

In file backend/optimizer/geqo/geqo_eval.c, routine geqo_joinrel_size, the present hack for MAXINT overflow is to set the Postgres integer value of rel->size to its logarithm. Modifications of Rel in backend/nodes/relation.h will surely have severe impacts on the whole Postgres implementation.

backend/optimizer/geqo/geqo_eval.c ¥Õ¥¡¥¤¥ë¤Î geqo_joinrel_size ½èÍý¤Ë¤ª¤¤¤Æ¡¢ rel->size ¤È¤¤¤¦ Postgres À°¿ôÃͤÎÂпô¤òÀßÄꤹ¤ë¤¿¤á¤Ë¡¢ MAXINT ¥ª¡¼¥Ð¡¼¥Õ¥í¡¼¤È¤¤¤¦ÌäÂê¤ò²ò·è¤·¤Ê¤±¤ì¤Ð¤¤¤±¤Þ¤»¤ó¡£ backend/nodes/relation.h ¥Õ¥¡¥¤¥ë¤Î Rel ¤ÎÊѹ¹¤Ï¡¢³Î¼Â¤Ë Postgres Á´È̤ËÂ礭¤¯±Æ¶Á¤òÍ¿¤¨¤ë¤³¤È¤Ë¤Ê ¤ê¤Þ¤¹¡£

¥á¥â¥ê¸Ï³é¤Ë¤Ä¤¤¤Æ¤Î²ò·èºö¤Îõµá

Memory exhaustion may occur with more than 10 relations involved in a query. In file backend/optimizer/geqo/geqo_eval.c, routine gimme_tree is recursively called. Maybe I forgot something to be freed correctly, but I dunno what. Of course the rel data structure of the join keeps growing and growing the more relations are packed into it. Suggestions are welcome :-(

Ì䤤¹ç¤ï¤»Æâ¤Ë 10 ¸Ä°Ê¾å¤Î¥ê¥ì¡¼¥·¥ç¥ó¤¬¤¢¤ë¤È¡¢¥á¥â¥ê¤ò»È¤¤²Ì¤¿¤·¤Æ ¤·¤Þ¤¹¤³¤È¤¬¤¢¤ê¤Þ¤¹¡£ backend/optimizer/geqo/geqo_eval.c ¥Õ¥¡¥¤¥ë¤Ç¤Ï gimme_tree ½èÍý¤¬ºÆµ¢Åª¤Ë¸Æ¤Ó½Ð¤µ¤ì¤Þ¤¹¡£¤ª¤½¤é ¤¯²¿¤«¤ò¤Á¤ã¤ó¤È³«Êü¤·¤Æ¤¤¤Ê¤¤¤Î¤À¤È¹Í¤¨¤Æ¤¤¤ë¤Ç¤¹¤¬¡¢¤Þ¤ÀȽÌÀ¤Ç¤­¤Æ ¤¤¤Þ¤»¤ó¡£¤â¤Á¤í¤ó join ¤Î rel ¥Ç¡¼¥¿¹½Â¤ÂΤϥê¥ì¡¼¥·¥ç¥ó¤¬¤¢¤ì¤Ð¤¢¤ë¤Û ¤ÉÈîÂ礷¤Æ¤¤¤­¤Þ¤¹¡£²¿¤«²ò·èºö¤¬¤Ê¤¤¤Ç¤·¤ç¤¦¤« :-(

»²¹Í»ñÎÁ

GEQ¥¢¥ë¥´¥ê¥º¥à´ØÏ¢¾ðÊó

The Hitch-Hiker's Guide to Evolutionary Computation, Jörg Heitkötter and David Beasley, InterNet resource, The Design and Implementation of the Postgres Query Optimizer, Z. Fong, University of California, Berkeley Computer Science Department, Fundamentals of Database Systems, R. Elmasri and S. Navathe, The Benjamin/Cummings Pub., Inc..

FAQ in comp.ai.genetic is available at Encore.

comp.ai.genetic¤Î FAQ ¤Ï Encore ¤«¤éÆþ¼ê¤Ç¤­¤Þ¤¹¡£

File planner/Report.ps in the 'postgres-papers' distribution.

'postgres-papers' ÇÛÉÛʪÆâ¤Î planner/Report.ps ¥Õ¥¡¥¤¥ë¡£