Skip site navigation (1) Skip section navigation (2)

Re: Crappy performance even though not swapping

From: "Phillip Smith" <phillip(dot)smith(at)weatherbeeta(dot)com(dot)au>
To: "'Neil Aggarwal'" <neil(at)JAMMConsulting(dot)com>,<pgsql-novice(at)postgresql(dot)org>
Subject: Re: Crappy performance even though not swapping
Date: 2007-02-28 03:21:11
Message-ID: 007301c75ae7$7eef5db0$9b0014ac@wbaus090 (view raw or flat)
Thread:
Lists: pgsql-novice
I'm not sure if a primary key on acct_num and exemption_code would help or
be any faster on the insert...?

ALTER TABLE "exemptions" ADD CONSTRAINT "exemptions_acct_num_pkey" PRIMARY
KEY (acct_num, exemption_code);

I had a similar problem on a nightly mass import / update which I worked
around by deleting the index, running the import then re-creating the index
in the same transaction block...

~p

-----Original Message-----
From: pgsql-novice-owner(at)postgresql(dot)org
[mailto:pgsql-novice-owner(at)postgresql(dot)org] On Behalf Of Neil Aggarwal
Sent: Wednesday, 28 February 2007 14:14
To: pgsql-novice(at)postgresql(dot)org
Subject: Re: [NOVICE] Crappy performance even though not swapping

Hello all:

I read the performance tips section of the documentation
and tried removing an index I had on the table.  Once I
did that, the performance seems to keep to the level
when my program first runs.

Here is my table:

CREATE TABLE "exemptions" (
	acct_num	varchar(13) not null,
	tax_district		char(3),
	exemption_code		char(3),
	exemption_description	varchar(50)
);

I had this index on it:
CREATE INDEX "exemptions_acct_num" on "exemptions" ("acct_num");

I can't create a unique index since there are repeat rows for
the account number when it has a different exemption code.

I am completely surprised by how much performance degredation
occurs with the index vs. without it.

Do unique indexes also have such a large impact on insert performance?

Will a non-unique index such as defined above help much with queries or
will the improvement be negligible?

Is there a better type of index to use?  The queries against this table
will almost always be looking to retrieve a set of rows by account number.

Thanks,	
	Neil

--
Neil Aggarwal, (214)986-3533, www.JAMMConsulting.com
FREE! Eliminate junk email and reclaim your inbox.
Visit http://www.spammilter.com for details.

-----Original Message-----
From: pgsql-novice-owner(at)postgresql(dot)org
[mailto:pgsql-novice-owner(at)postgresql(dot)org] On Behalf Of Neil Aggarwal
Sent: Tuesday, February 27, 2007 8:50 PM
To: pgsql-novice(at)postgresql(dot)org
Subject: [NOVICE] Crappy performance even though not swapping

Hello:

I have a Java program that is trying to import over 8 million 
rows from a text file.

When the program starts up, it runs fine, but after a while
it begins to crawl.

This is usually symptomatic of a machine that started swapping,
but take a look at the attached output from top.

I am using a LOT of memory, but the swap is still very 
low.  I don't think the machine should be paging to disk.

The CPU states show that the cpus are spending most of their time 
in an idle state.  The process list shows the postmaster and java 
processes are less than 10 percent the CPU cycles.

Having said that, the load average is still about 2.

Any ideas what could be going on?

Thanks,	
	Neil

--
Neil Aggarwal, (214)986-3533, www.JAMMConsulting.com
FREE! Eliminate junk email and reclaim your inbox.
Visit http://www.spammilter.com for details.


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match


*******************Confidentiality and Privilege Notice*******************

The material contained in this message is privileged and confidential to
the addressee.  If you are not the addressee indicated in this message or
responsible for delivery of the message to such person, you may not copy
or deliver this message to anyone, and you should destroy it and kindly
notify the sender by reply email.

Information in this message that does not relate to the official business
of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta.
Weatherbeeta, its employees, contractors or associates shall not be liable
for direct, indirect or consequential loss arising from transmission of this
message or any attachments

In response to

pgsql-novice by date

Next:From: Phillip SmithDate: 2007-02-28 03:24:38
Subject: Re: Crappy performance even though not swapping
Previous:From: Neil AggarwalDate: 2007-02-28 03:18:43
Subject: Re: Crappy performance even though not swapping

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group