Re: Postgres scalability and performance on windows

From: "J(dot) Andrew Rogers" <jrogers(at)neopolitan(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gopal <gopal(at)getmapping(dot)com>, "Pgsql-Performance ((E-mail))" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Postgres scalability and performance on windows
Date: 2006-11-28 16:51:05
Message-ID: 620D2117-5AFE-4CAE-8E7F-5E57BC587D70@neopolitan.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


On Nov 28, 2006, at 8:24 AM, Tom Lane wrote:
> "Gopal" <gopal(at)getmapping(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Carlos H. Reimer 2006-11-28 19:01:25 RES: Priority to a mission critical transaction
Previous Message Tom Lane 2006-11-28 16:24:42 Re: Postgres scalability and performance on windows