<HTML><BODY><div><div>Thank you, Jeff. Specifying wms_extent in metadata has helped. I didn’t think that all these efforts (reading tens of thousands child tables) was just to figure out layer extent. Somehow was thinking that it is taken automatically from mapfile header.</div><div>I need to check just for an interest to read such layer through OGR library and see how much it will take to complete layer.GetExtent() :D </div><div>Regarding close_connection=defer directive. Does it mean that if I use it the connection will be opened for the whole time wms is being viewed by user and all the select queries will use this exact connection. While if I wouldn’t use this directive: different select queries would have different connections opened? Or do I misunderstand something?<br>Sincerely, Dimitri</div><div> </div><div> </div><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">Среда, 21 октября 2020, 22:01 +03:00 от mapserver-users-request@lists.osgeo.org:<br> <div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_16033068650217906992_BODY">Send mapserver-users mailing list submissions to<br><a href="/compose?To=mapserver%2dusers@lists.osgeo.org">mapserver-users@lists.osgeo.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br><a href="https://lists.osgeo.org/mailman/listinfo/mapserver-users" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br>or, via email, send a message with subject or body 'help' to<br><a href="/compose?To=mapserver%2dusers%2drequest@lists.osgeo.org">mapserver-users-request@lists.osgeo.org</a><br><br>You can reach the person managing the list at<br><a href="/compose?To=mapserver%2dusers%2downer@lists.osgeo.org">mapserver-users-owner@lists.osgeo.org</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of mapserver-users digest..."<br><br><br>Today's Topics:<br><br> 1. problem with getcapabilities xml generation when layer is<br> using data from postgresql inherited table (Zmitser Kozhukh)<br> 2. Re: problem with getcapabilities xml generation when layer is<br> using data from postgresql inherited table (Jeff McKenna)<br> 3. Re: problem with getcapabilities xml generation when layer is<br> using data from postgresql inherited table (Jeff McKenna)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 21 Oct 2020 13:14:58 +0300<br>From: Zmitser Kozhukh <<a href="/compose?To=zmitserk@mail.ru">zmitserk@mail.ru</a>><br>To: mapserver-users <<a href="/compose?To=mapserver%2dusers@lists.osgeo.org">mapserver-users@lists.osgeo.org</a>><br>Subject: [mapserver-users] problem with getcapabilities xml generation<br>when layer is using data from postgresql inherited table<br>Message-ID: <<a href="/compose?To=1603275298.195396547@f418.i.mail.ru">1603275298.195396547@f418.i.mail.ru</a>><br>Content-Type: text/plain; charset="utf-8"<br><br><br>Good time of the day, may be it is my misconception, but I used to think that generation of GetCapabilities xml doesn’t require checking that the data source of the layer is valid and it really has data etc. I was thinking that this is just a matter of converting metadata from mapfile to xml format by certain rules.<br>But it appears, that it is different from what I have been thinking. I am having a wms service that reads data from inherited postgresql table (table inherits data from many thousands of childs table) and it takes infinity to generate getcapabilities xml document:<br><a href="https://gis.lesprojekt.cz/cgi-bin/mapserv?map=/home/dima/maps/olu/european_openlandusemap.map&service=WMS&request=GetCapabilities" target="_blank">https://gis.lesprojekt.cz/cgi-bin/mapserv?map=/home/dima/maps/olu/european_openlandusemap.map&service=WMS&request=GetCapabilities</a><br>With other wms services that use just ordinary tables as data source it (this instance of mapserver) works just fine.<br>So my questions is : is it possible to change the code of mapserver not to check all child tables and instead just generate getcapabilities xml from the metadata in mapfile?<br>Or may be someone had this issue and found other solution?<br>I think in older versions of mapserver (this concrete instance is version 7.2.0 ) inherited tables didn’t cause any troubles.<br>Sincerely, Dimitri<br> <br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="http://lists.osgeo.org/pipermail/mapserver-users/attachments/20201021/397456cd/attachment-0001.html" target="_blank">http://lists.osgeo.org/pipermail/mapserver-users/attachments/20201021/397456cd/attachment-0001.html</a>><br><br>------------------------------<br><br>Message: 2<br>Date: Wed, 21 Oct 2020 08:31:39 -0300<br>From: Jeff McKenna <<a href="/compose?To=jmckenna@gatewaygeomatics.com">jmckenna@gatewaygeomatics.com</a>><br>To: <a href="/compose?To=mapserver%2dusers@lists.osgeo.org">mapserver-users@lists.osgeo.org</a><br>Subject: Re: [mapserver-users] problem with getcapabilities xml<br>generation when layer is using data from postgresql inherited table<br>Message-ID:<br><<a href="/compose?To=aec3cd68%2d66bb%2d237e%2d5028%2dcad64d11e575@gatewaygeomatics.com">aec3cd68-66bb-237e-5028-cad64d11e575@gatewaygeomatics.com</a>><br>Content-Type: text/plain; charset=utf-8; format=flowed<br><br>Hi Dimitri,<br><br>For database connections such as PostgreSQL I always manually set the<br>LAYER metadata "wms_extent" for each layer (the actual bounding box of<br>that specific table in PostGIS), so that MapServer does not have to<br>calculate the extents for the GetCapabilities for each layer. (I<br>believe this is also mentioned as a "WARNING" in the GetCapabilities<br>response).<br><br>-jeff<br><br><br><br>--<br>Jeff McKenna<br>MapServer Consulting and Training Services<br>co-founder of FOSS4G<br><a href="http://gatewaygeo.com/" target="_blank">http://gatewaygeo.com/</a><br><br><br><br>On 2020-10-21 7:14 a.m., Zmitser Kozhukh wrote:<br>> Good time of the day, may be it is my misconception, but I used to think<br>> that generation of GetCapabilities xml doesn’t require checking that the<br>> data source of the layer is valid and it really has data etc. I was<br>> thinking that this is just a matter of converting metadata from mapfile<br>> to xml format by certain rules.<br>> But it appears, that it is different from what I have been thinking. I<br>> am having a wms service that reads data from inherited postgresql table<br>> (table inherits data from many thousands of childs table) and it takes<br>> infinity to generate getcapabilities xml document:<br>> <a href="https://gis.lesprojekt.cz/cgi-bin/mapserv?map=/home/dima/maps/olu/european_openlandusemap.map&service=WMS&request=GetCapabilities" target="_blank">https://gis.lesprojekt.cz/cgi-bin/mapserv?map=/home/dima/maps/olu/european_openlandusemap.map&service=WMS&request=GetCapabilities</a><br>> With other wms services that use just ordinary tables as data source it<br>> (this instance of mapserver) works just fine.<br>> So my questions is : is it possible to change the code of mapserver not<br>> to check all child tables and instead just generate getcapabilities xml<br>> from the metadata in mapfile?<br>> Or may be someone had this issue and found other solution?<br>> I think in older versions of mapserver (this concrete instance<br>> is version 7.2.0 ) inherited tables didn’t cause any troubles.<br>> Sincerely, Dimitri<br>><br><br><br><br><br><br>------------------------------<br><br>Message: 3<br>Date: Wed, 21 Oct 2020 08:35:56 -0300<br>From: Jeff McKenna <<a href="/compose?To=jmckenna@gatewaygeomatics.com">jmckenna@gatewaygeomatics.com</a>><br>To: <a href="/compose?To=mapserver%2dusers@lists.osgeo.org">mapserver-users@lists.osgeo.org</a><br>Subject: Re: [mapserver-users] problem with getcapabilities xml<br>generation when layer is using data from postgresql inherited table<br>Message-ID:<br><<a href="/compose?To=add5b6e5%2d479e%2d4f4e%2d61ef%2d5570c1e94ab1@gatewaygeomatics.com">add5b6e5-479e-4f4e-61ef-5570c1e94ab1@gatewaygeomatics.com</a>><br>Content-Type: text/plain; charset=utf-8; format=flowed<br><br>I should also mention that for each of my PostgreSQL layers I always<br>enable connection pooling for each LAYER:<br><br> PROCESSING "CLOSE_CONNECTION=DEFER"<br><br>Although my notes don't answer your specific question, these are the<br>steps that I always follow.<br><br>-jeff<br><br><br><br>--<br>Jeff McKenna<br>MapServer Consulting and Training Services<br>co-founder of FOSS4G<br><a href="http://gatewaygeo.com/" target="_blank">http://gatewaygeo.com/</a><br><br><br>On 2020-10-21 7:14 a.m., Zmitser Kozhukh wrote:<br>> Good time of the day, may be it is my misconception, but I used to think<br>> that generation of GetCapabilities xml doesn’t require checking that the<br>> data source of the layer is valid and it really has data etc. I was<br>> thinking that this is just a matter of converting metadata from mapfile<br>> to xml format by certain rules.<br>> But it appears, that it is different from what I have been thinking. I<br>> am having a wms service that reads data from inherited postgresql table<br>> (table inherits data from many thousands of childs table) and it takes<br>> infinity to generate getcapabilities xml document:<br>> <a href="https://gis.lesprojekt.cz/cgi-bin/mapserv?map=/home/dima/maps/olu/european_openlandusemap.map&service=WMS&request=GetCapabilities" target="_blank">https://gis.lesprojekt.cz/cgi-bin/mapserv?map=/home/dima/maps/olu/european_openlandusemap.map&service=WMS&request=GetCapabilities</a><br>> With other wms services that use just ordinary tables as data source it<br>> (this instance of mapserver) works just fine.<br>> So my questions is : is it possible to change the code of mapserver not<br>> to check all child tables and instead just generate getcapabilities xml<br>> from the metadata in mapfile?<br>> Or may be someone had this issue and found other solution?<br>> I think in older versions of mapserver (this concrete instance<br>> is version 7.2.0 ) inherited tables didn’t cause any troubles.<br>> Sincerely, Dimitri<br>><br><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>mapserver-users mailing list<br><a href="/compose?To=mapserver%2dusers@lists.osgeo.org">mapserver-users@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/mapserver-users" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-users</a><br><br>------------------------------<br><br>End of mapserver-users Digest, Vol 153, Issue 13<br>************************************************</div></div></div></div></blockquote><br><div data-signature-widget="container"><div data-signature-widget="content"><div>--<br>Zmitser Kozhukh</div></div></div></div></BODY></HTML>