On Thu, Apr 16, 2009 at 9:48 PM, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Apr 17, 2009 at 9:22 AM, Grzegorz Jaśkiewicz gryz...@gmail.com 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
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
Grzegorz Jaśkiewicz wrote:
On Wed, Apr 15, 2009 at 1:25 PM, Simon Riggs si...@2ndquadrant.com 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
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.
I wrote:
=?ISO-8859-1?Q?Christian_Schr=F6der?= c...@deriva.de 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
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
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:
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
2009/4/15 Christian Schröder c...@deriva.de:
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
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 really fast
On Wed, Apr 15, 2009 at 1:25 PM, Simon Riggs si...@2ndquadrant.com 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
=?ISO-8859-1?Q?Christian_Schr=F6der?= c...@deriva.de 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
13 matches
Mail list logo
