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

Re: Select * is very slow

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: "shaiju(dot)ck" <shaiju(dot)ck(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Select * is very slow
Date: 2010-11-08 15:23:32
Message-ID: AANLkTi=ar5kF2j8xjbur1zugQv2Sj6ZOVhamm5kr-7_Y@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
Hello

do you use a VACUUM statement?

Regards

Pavel Stehule

2010/11/8 shaiju.ck <shaiju(dot)ck(at)gmail(dot)com>:
> Hi, I have a table employee with 33 columns. The table have 200 records now.
> Select * from employee takes 15 seconds to fetch the data!!! Which seems to
> be very slow. But when I say select id,name from empoyee it executes in
> 30ms. Same pefromance if I say select count(*) from emloyee. Why the query
> is slow if I included all the columns in the table. As per my understanding
> , number of columns should not be having a major impact on the query
> performance. I have increased the shared_buffres to 1024MB, but no
> improvement. I have noticed that the query "show shared_buffers" always show
> 8MB.Why is this? Does it mean that changing the shared_buffers in config
> file have no impact? Can anybody help? Shaiju
> ________________________________
> View this message in context: Select * is very slow
> Sent from the PostgreSQL - performance mailing list archive at Nabble.com.
>

In response to

pgsql-performance by date

Next:From: Thom BrownDate: 2010-11-08 15:30:30
Subject: Re: Select * is very slow
Previous:From: Marti RaudseppDate: 2010-11-08 14:23:27
Subject: Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?

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