Re: Query performance issue

From: Jayadevan M <Jayadevan(dot)Maymala(at)ibsplc(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PGSQL Performance <pgsql-performance(at)postgresql(dot)org>, pgsql-performance-owner(at)postgresql(dot)org
Subject: Re: Query performance issue
Date: 2011-08-31 10:07:40
Message-ID: OF23F3E566.D456F57C-ON652578FD.00372A6C-652578FD.0037A251@ibsplc.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hello,

> Please run EXPLAIN ANALYZE on the query and post that, it's hard to say
> what's wrong from just the query plan, without knowing where the time is

> actually spent. And the schema of the tables involved, and any indexes
> on them. (see also http://wiki.postgresql.org/wiki/SlowQueryQuestions)
The details of the tables and indexes may take a bit of effort to explain.
Will do that.
I remembered that a similar query took about 90 seconds to run a few days
ago. Now that is also taking a few minutes to run. In between, we made
some changes to a few tables (the tables are about 9-10 GB each). This was
to fix some issue in conversion from CHARACTER VARYING to BOOLEAN on
PostgreSQL (some columns in Oracle were of type VARCHAR, to store BOOLEAN
values. We changed that to BOOLEAN in PostgreSQL to resolve some issues at
the jdbc level). The alters were of similar type -

ALTER TABLE cusdynatr ALTER tstflg TYPE boolean USING CASE WHEN tstflg =
'1' THEN true WHEN tstflg = '0' then FALSE END;

Do such alters result in fragmentation at storage level?

Regards,
Jayadevan

DISCLAIMER:

"The information in this e-mail and any attachment is intended only for
the person to whom it is addressed and may contain confidential and/or
privileged material. If you have received this e-mail in error, kindly
contact the sender and destroy all copies of the original communication.
IBS makes no warranty, express or implied, nor guarantees the accuracy,
adequacy or completeness of the information contained in this email or any
attachment and is not liable for any errors, defects, omissions, viruses
or for resultant loss or damage, if any, direct or indirect."

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jayadevan M 2011-08-31 10:51:46 Re: Query performance issue
Previous Message Sushant Sinha 2011-08-31 09:37:20 Re: Query performance issue