Tom Lane wrote:
I've applied a patch for this. It will be in 8.3.8, or if you're
in a hurry you can grab it from our CVS server or here:
Thanks a lot for your effort and the quick response!
Regards,
Christian
--
Deriva GmbH Tel.: +49 551 489500-42
Financial IT an
On Fri, Apr 17, 2009 at 9:22 AM, Grzegorz Jaśkiewicz wrote:
> just out of curiosity - when was it introduced, ie - which version was
> the first affected ? We're still on 8.3.5 here.
(I had no idea release-notes have date), it got in by 8.3.4 (changed
right after 8.3.3 was released).
>
> --
> G
On Thu, Apr 16, 2009 at 9:48 PM, Tom Lane wrote:
>
> I've applied a patch for this. It will be in 8.3.8, or if you're
> in a hurry you can grab it from our CVS server or here:
>
> http://archives.postgresql.org/message-id/20090416204228.57931754...@cvs.postgresql.org
just out of curiosity - whe
I wrote:
> =?ISO-8859-1?Q?Christian_Schr=F6der?= writes:
>> This is the query:
>> select isin from ts_frontend.attachment_isins full OUTER JOIN
>> ts_frontend.rec_isins using (attachment,isin) WHERE attachment=2698120
>> GROUP BY isin limit 1000;
> Hmm. It seems 8.3 is failing to push the at
On Thu, Apr 16, 2009 at 01:31:45PM +0200, Christian Schröder wrote:
> Stupid question: Do I have to analyze again or perform a reindex after
> adding the index?
No, it's a regression in PG's handling of outer joins---it used to
realise that this was a possible optimisation, but now it doesn't.
T
Grzegorz Jaśkiewicz wrote:
On Wed, Apr 15, 2009 at 1:25 PM, Simon Riggs wrote:
The cost of the query seems accurate, so the absence of
attachment_isins_attachment_idx on the 8.3 plan looks to be the reason.
There's no way it would choose to scan 8115133 rows on the pkey if the
other index wa
=?ISO-8859-1?Q?Christian_Schr=F6der?= writes:
> This is the query:
> select isin from ts_frontend.attachment_isins full OUTER JOIN
> ts_frontend.rec_isins using (attachment,isin) WHERE attachment=2698120
> GROUP BY isin limit 1000;
Hmm. It seems 8.3 is failing to push the attachment=2698120
On Wed, Apr 15, 2009 at 1:25 PM, Simon Riggs wrote:
> The cost of the query seems accurate, so the absence of
> attachment_isins_attachment_idx on the 8.3 plan looks to be the reason.
> There's no way it would choose to scan 8115133 rows on the pkey if the
> other index was available and usable.
On Wed, 2009-04-15 at 14:04 +0200, Christian Schröder wrote:
> Grzegorz Jaśkiewicz wrote:
> > set work_mem=24000; before running the query.
> >
> > postgres is doing merge and sort on disc, that's always slow.
> >
> Ok, but why is the plan different in 8.2? As you can see the same query
> is r
2009/4/15 Christian Schröder :
> Grzegorz Jaśkiewicz wrote:
>>
>> set work_mem=24000; before running the query.
>>
>> postgres is doing merge and sort on disc, that's always slow.
>>
>
> Ok, but why is the plan different in 8.2? As you can see the same query is
> really fast in 8.2, but slow in 8.3
Grzegorz Jaśkiewicz wrote:
set work_mem=24000; before running the query.
postgres is doing merge and sort on disc, that's always slow.
Ok, but why is the plan different in 8.2? As you can see the same query
is really fast in 8.2, but slow in 8.3.
is there an index on column isin ?
There
set work_mem=24000; before running the query.
postgres is doing merge and sort on disc, that's always slow.
is there an index on column isin ?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-gen
Hi list,
we have just migrated one of our databases from 8.2.12 to 8.3.7. We now
experience a strange problem: A query that was really fast on the 8.2
server is now much slower on the 8.3 server (1 ms vs. 60 sec). I had a
look at the query plan and it is completely different. Both servers run
13 matches
Mail list logo
