Joe --
>
> From: Joe Van Dyk
>To: Greg Williamson
>Cc: "pgsql-performance@postgresql.org"
>Sent: Friday, April 5, 2013 7:56 PM
>Subject: Re: [PERFORM] slow joins?
>
>
>On Fri, Apr 5, 2013 at 6:54 PM, Greg Williamson
>wrote:
>
>Joe --
>>
>>>
On Fri, Apr 5, 2013 at 6:54 PM, Greg Williamson wrote:
> Joe --
>
> >
> > From: Joe Van Dyk
> >To: pgsql-performance@postgresql.org
> >Sent: Friday, April 5, 2013 6:42 PM
> >Subject: Re: [PERFORM] slow joins?
> >
> >
> >(
> https://gist.github.com/joevandyk/df0df70
Joe --
>
> From: Joe Van Dyk
>To: pgsql-performance@postgresql.org
>Sent: Friday, April 5, 2013 6:42 PM
>Subject: Re: [PERFORM] slow joins?
>
>
>(https://gist.github.com/joevandyk/df0df703f3fda6d14ae1/raw/c15cae813913b7f8c35b24b467a0c732c0100d79/gistfile1.txt
> s
If I disable sequential scans, hash joins, and merge joins, the query plans
become the same and performance on the first slow one is much improved.
Is there something else I can do to avoid this problem?
below also at
https://gist.github.com/joevandyk/34e31b3ad5cccb730a50/raw/8081a4298ba50ac93a86
(
https://gist.github.com/joevandyk/df0df703f3fda6d14ae1/raw/c15cae813913b7f8c35b24b467a0c732c0100d79/gistfile1.txtshows
a non-wrapped version of the queries and plan)
On Fri, Apr 5, 2013 at 6:38 PM, Joe Van Dyk wrote:
> On 9.2.4, running two identical queries except for the value of a column
>
On 9.2.4, running two identical queries except for the value of a column in
the WHERE clause. Postgres is picking very different query plans, the first
is much slower than the second.
Any ideas on how I can speed this up? I have btree indexes for all the
columns used in the query.
explain analyz
On Fri, Apr 5, 2013 at 11:54 AM, Dave Johansen wrote:
> On Sat, Feb 26, 2011 at 2:38 PM, Dave Johansen
> wrote:
>>
>> Unfortunately, I'm running 8.3.3 and to my knowledge the windowing stuff
>> wasn't added til 8.4.
>> Dave
>>
>> On Feb 26, 2011 2:06 PM, "Josh Berkus" wrote:
>> > Dave,
>> >
>> >
On Sat, Feb 26, 2011 at 2:38 PM, Dave Johansen
wrote:
>
> Unfortunately, I'm running 8.3.3 and to my knowledge the windowing stuff
> wasn't added til 8.4.
> Dave
>
> On Feb 26, 2011 2:06 PM, "Josh Berkus" wrote:
> > Dave,
> >
> > Why not test the windowing version I posted?
We finally have moved
Mark Davidson wrote:
> CONSTRAINT data_area_pkey PRIMARY KEY (data_id , area_id ),
So the only index on this 250 million row table starts with the ID
of the point, but you are joining to it by the ID of the area.
That's requires a sequential scan of all 250 million rows. Switch
the order of t
Hi All,
Hoping someone can help me out with some performance issues I'm having with
the INDEX on my database. I've got a database that has a data table
containing ~55,000,000 rows which have point data and an area table
containing ~3,500 rows which have polygon data. A user queries the data by
sel
On Fri, Apr 5, 2013 at 9:55 AM, Franck Routier wrote:
> Le 04/04/2013 21:08, Tom Lane a écrit :
> Maybe the statistics tables for sandia and saneds are in a bad shape ?
> (don't know how to check this).
>
> Regards,
>
> Franck
>
>
Could this be caused by system table bloat?
Also, can you check h
On Fri, Apr 5, 2013 at 8:55 AM, Franck Routier wrote:
> Le 04/04/2013 21:08, Tom Lane a écrit :
>
>> Franck Routier writes:
>>>
>>> The request is not using any function. It looks like this:
>>> [ unexciting query ]
>>
>> Hmph. Can't see any reason for that to take a remarkably long time to
>> p
Franck Routier writes:
> Le 04/04/2013 21:08, Tom Lane a écrit :
>> Hmph. Can't see any reason for that to take a remarkably long time to
>> plan. Can you put together a self-contained test case demonstrating
>> excessive planning time? What PG version is this, anyway?
> What I notice is that
Le 04/04/2013 21:08, Tom Lane a écrit :
Franck Routier writes:
The request is not using any function. It looks like this:
[ unexciting query ]
Hmph. Can't see any reason for that to take a remarkably long time to
plan. Can you put together a self-contained test case demonstrating
excessive p
14 matches
Mail list logo
