In query some are the repeatative information like below value repeating 3
times.
"19.548124415111626 73.21900819489186"
You can create the spatial index on spatial data which will improve the
performance of the query & off course ANALYZE after creating index.
--
Thanks & Regards
Dhaval Jai
Dear all,
Can anyone Please guide me with some suggestions on how to tune the
below query as I needed to perform the below query as faster as i can.
I have 3 tables on which the query runs:
pdc_uima=# select
pg_size_pretty(pg_total_relation_size('page_content_demo'));
pg_size_pretty
---
=?ISO-8859-1?Q?Andreas_For=F8_Tollefsen?= writes:
> This is a query i am working on now. It creates an intersection of two
> geometries. One is a grid of 0.5 x 0.5 decimal degree sized cells, while the
> other is the country geometries of all countries in the world for a certain
> year.
Hm, are y
On Mon, Mar 07, 2011 at 10:49:48PM +0100, Andreas For Tollefsen wrote:
- The synchronous_commit off increased the TPS, but not the speed of the below
- query.
-
- Oleg:
- This is a query i am working on now. It creates an intersection of two
- geometries. One is a grid of 0.5 x 0.5 decimal degree
The synchronous_commit off increased the TPS, but not the speed of the below
query.
Oleg:
This is a query i am working on now. It creates an intersection of two
geometries. One is a grid of 0.5 x 0.5 decimal degree sized cells, while the
other is the country geometries of all countries in the worl
On Tue, Feb 22, 2011 at 9:07 PM, Robert Haas wrote:
> On Fri, Feb 4, 2011 at 7:08 AM, Ivan Voras wrote:
>> -> BitmapAnd (cost=1282.94..1282.94
>> rows=1430 width=0) (actual time=5.508..5.508 rows=0 loops=1)
>> -> Bitmap Inde
On Wed, Mar 2, 2011 at 6:12 PM, sverhagen wrote:
> Thanks for your help already!
> Hope you're up for some more :-)
>
>
> Andy Colson wrote:
>>
>> First off, excellent detail.
>>
>> Second, your explain analyze was hard to read... but since you are not
>> really interested in your posted query, I
Jon Nelson wrote:
> What is the difference between a plain join and a semi join?
As soon as a semi join finds a match it stops looking for more.
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
On Mon, Mar 7, 2011 at 2:00 PM, Tom Lane wrote:
> Jon Nelson writes:
>> I was hoping that somebody could help me understand the differences
>> between three plans.
>> All of the plans are updating a table using a second table, and should
>> be logically equivalent.
>> Two of the plans use joins,
On Mon, Mar 7, 2011 at 1:07 PM, Jon Nelson wrote:
> Originally, I posted to -general but I found some time to write some
> samples, and realized it's probably more of a performance question.
>
> The original post is here:
> http://archives.postgresql.org/pgsql-general/2011-03/msg00198.php
>
> I wa
Jon Nelson writes:
> I was hoping that somebody could help me understand the differences
> between three plans.
> All of the plans are updating a table using a second table, and should
> be logically equivalent.
> Two of the plans use joins, and one uses an exists subquery.
> One of the plans uses
On Thu, Mar 3, 2011 at 9:55 AM, Andy Colson wrote:
>> explain analyze SELECT events_events.* FROM events_events
>> JOIN events_eventdetails customerDetails
>> ON events_events.transactionid = customerDetails.transactionid
>> AND customerDetails.keyname='customer_id'
>> AND sub
Originally, I posted to -general but I found some time to write some
samples, and realized it's probably more of a performance question.
The original post is here:
http://archives.postgresql.org/pgsql-general/2011-03/msg00198.php
I was hoping that somebody could help me understand the differences
2011/3/3 Arjen van der Meijden :
> On 2-3-2011 16:29 Robert Haas wrote:
>>
>> On Mon, Feb 28, 2011 at 2:09 PM, Josh Berkus wrote:
>>>
>>> Does anyone have the hardware to test FlashCache with PostgreSQL?
>>>
>>> http://perspectives.mvdirona.com/2010/04/29/FacebookFlashcache.aspx
>>>
>>> I'd be int
On Mon, 7 Mar 2011, Andreas For? Tollefsen wrote:
Ok. Cheers. I will do some more testing on my heavy PostGIS queries which
often takes hours to complete.
I'd like to see hours long queries :) EXPLAIN ANALYZE
Thanks.
Andreas
2011/3/7 Kenneth Marshall
On Mon, Mar 07, 2011 at 03:17:05PM +
Ok. Cheers. I will do some more testing on my heavy PostGIS queries which
often takes hours to complete.
Thanks.
Andreas
2011/3/7 Kenneth Marshall
> On Mon, Mar 07, 2011 at 03:17:05PM +0100, Andreas For? Tollefsen wrote:
> > Thanks, Ken.
> >
> > It seems like the tip to turn off synchronous_com
On Mon, Mar 07, 2011 at 03:17:05PM +0100, Andreas For? Tollefsen wrote:
> Thanks, Ken.
>
> It seems like the tip to turn off synchronous_commit did the trick:
>
> /usr/lib/postgresql/8.4/bin/pgbench -T 60 test1
> starting vacuum...end.
> transaction type: TPC-B (sort of)
> scaling factor: 1
> que
Thanks, Ken.
It seems like the tip to turn off synchronous_commit did the trick:
/usr/lib/postgresql/8.4/bin/pgbench -T 60 test1
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 1
duration: 60 s
number of transactions actually proces
On Mon, Mar 07, 2011 at 02:45:03PM +0100, Andreas For? Tollefsen wrote:
> Hi,
>
> I am running Postgresql 8.4.7 with Postgis 2.0 (for raster support).
> Server is mainly 1 user for spatial data processing. This involves queries
> that can take hours.
>
> This is running on a ubuntu 10.10 Server w
Hi,
I am running Postgresql 8.4.7 with Postgis 2.0 (for raster support).
Server is mainly 1 user for spatial data processing. This involves queries
that can take hours.
This is running on a ubuntu 10.10 Server with Core2Duo 6600 @ 2.4 GHZ, 6 GB
RAM.
My postgresql.conf:
# - Memory -
shared_buffer
20 matches
Mail list logo
