Re: Postgres scalability and performance on windows
От | J. Andrew Rogers |
---|---|
Тема | Re: Postgres scalability and performance on windows |
Дата | |
Msg-id | 620D2117-5AFE-4CAE-8E7F-5E57BC587D70@neopolitan.com обсуждение исходный текст |
Ответ на | Re: Postgres scalability and performance on windows (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
On Nov 28, 2006, at 8:24 AM, Tom Lane wrote: > "Gopal" <gopal@getmapping.com> writes: >> This is the query and the schema.... >> ... >> select >> sum(area(intersection(snaptogrid(chunkgeometry,0.00000001), >> GeometryFromText('POLYGON((-0.140030845589332 >> 50.8208343077265,-0.138958398039148 >> 50.8478005422809,-0.0963639712296823 >> 50.8471133071392,-0.0974609286275892 >> 50.8201477285483,-0.140030845589332 >> 50.8208343077265))',4326))) * 100/ (0.00114901195862628)) as >> percentCover, > > So evidently area(intersection(snaptogrid(...))) takes about 300 > microsec per row. The PostGIS hackers would have to comment on > whether > that seems out-of-line or not, and whether you can make it faster. This is consistent with the typical cost for GIS geometry ops -- they are relatively expensive. When running queries against PostGIS fields for our apps, about half the CPU time will be spent inside the geometry ops. Fortunately, there is significant opportunity for improvement in the performance of the underlying code if anyone found the time to optimize (and uglify) it for raw speed. Cheers, J. Andrew Rogers
В списке pgsql-performance по дате отправления: