Thread: Slow SELECT on three or more clients
Hi!
Im new to PostgreSQL.
My current project uses PostgreSQL 7.3.4.
the problem is like this:
I have a table with 94 fields and a select with only one resultset in only one client consumes about 0.86 seconds.
The client executes three 'select' statements to perform the task which consumes 2.58 seconds.
With only one client this is acceptable, but the real problem is as i add more clients, it goes more and more slower.
for a single select with one field in one resultset, is 0.86 seconds normal?
I tried vacuuming and reindexing but to no avail.
the total record count in that particular table is 456,541.
Thanks in advance.
Im new to PostgreSQL.
My current project uses PostgreSQL 7.3.4.
the problem is like this:
I have a table with 94 fields and a select with only one resultset in only one client consumes about 0.86 seconds.
The client executes three 'select' statements to perform the task which consumes 2.58 seconds.
With only one client this is acceptable, but the real problem is as i add more clients, it goes more and more slower.
for a single select with one field in one resultset, is 0.86 seconds normal?
I tried vacuuming and reindexing but to no avail.
the total record count in that particular table is 456,541.
Thanks in advance.
* AMIR FRANCO D. JOVEN <amir@digi.ph> [061115 12:44]: > Hi! > > Im new to PostgreSQL. > > My current project uses PostgreSQL 7.3.4. Ancient. Upgrade it, especially if it's a new database. > > the problem is like this: > > I have a table with 94 fields and a select with only one resultset in only > one client consumes about 0.86 seconds. > The client executes three 'select' statements to perform the task which > consumes 2.58 seconds. > With only one client this is acceptable, but the real problem is as i add > more clients, it goes more and more slower. That depends upon: a) your table schema. b) the data in the tables. E.g. how big are rows, how many rows. c) the size of the result sets. d) your indexes? Andreas
AMIR FRANCO D. JOVEN wrote: > Hi! > > Im new to PostgreSQL. > > My current project uses PostgreSQL 7.3.4. Upgrading your version of PostgreSQL to 8.1 will give you significant benefits to performance. > > the problem is like this: > > I have a table with 94 fields and a select with only one resultset in > only one client consumes about 0.86 seconds. > The client executes three 'select' statements to perform the task > which consumes 2.58 seconds. > With only one client this is acceptable, but the real problem is as i > add more clients, it goes more and more slower. > > for a single select with one field in one resultset, is 0.86 seconds > normal? You will need to attach the query. EXPLAIN ANALYZE SELECT ... where SELECT ... is your query. That will help us work out what the problem is. 0.86 seconds might be slow for a query that returns 1 row, it might be fast for a query that returns a large set with complex joins and where conditions. Fast and slow are not objective terms. They are very dependent on the query. > > I tried vacuuming and reindexing but to no avail. > the total record count in that particular table is 456,541. > 456,541 is not all that many records. But again you will need to post more information for us to be able to assist. > Thanks in advance. >
Operating system and some of the basic PostreSQL config settings would be helpful, plus any info you have on your disks,the size of the relevant tables, their structure and indexes & vacuum/analyze status ... plus what others have said: Upgrade! There are considerable improvements in, well, *everything* !, since 7.3 (we havew some database atb 7.4.x and I considerthem out-of-date). Hopefully this list can provide help to get you through whatever your immediate crisis is, butdo consider planning for this as soon as time and resource permit. Data integrity is a _good_ thing! Greg Williamson DBA GlobeXplorer LLC -----Original Message----- From: pgsql-performance-owner@postgresql.org on behalf of Russell Smith Sent: Wed 11/15/2006 5:31 AM To: AMIR FRANCO D. JOVEN Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] Slow SELECT on three or more clients AMIR FRANCO D. JOVEN wrote: > Hi! > > Im new to PostgreSQL. > > My current project uses PostgreSQL 7.3.4. Upgrading your version of PostgreSQL to 8.1 will give you significant benefits to performance. > > the problem is like this: > > I have a table with 94 fields and a select with only one resultset in > only one client consumes about 0.86 seconds. > The client executes three 'select' statements to perform the task > which consumes 2.58 seconds. > With only one client this is acceptable, but the real problem is as i > add more clients, it goes more and more slower. > > for a single select with one field in one resultset, is 0.86 seconds > normal? You will need to attach the query. EXPLAIN ANALYZE SELECT ... where SELECT ... is your query. That will help us work out what the problem is. 0.86 seconds might be slow for a query that returns 1 row, it might be fast for a query that returns a large set with complex joins and where conditions. Fast and slow are not objective terms. They are very dependent on the query. > > I tried vacuuming and reindexing but to no avail. > the total record count in that particular table is 456,541. > 456,541 is not all that many records. But again you will need to post more information for us to be able to assist. > Thanks in advance. > ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings ------------------------------------------------------- Click link below if it is SPAM gsw@globexplorer.com "https://mailscanner.globexplorer.com/dspam/dspam.cgi?signatureID=455b17b2223071076418835&user=gsw@globexplorer.com&retrain=spam&template=history&history_page=1" !DSPAM:455b17b2223071076418835! -------------------------------------------------------
On 11/15/06, AMIR FRANCO D. JOVEN <amir@digi.ph> wrote: > Hi! > > Im new to PostgreSQL. > > My current project uses PostgreSQL 7.3.4. > > the problem is like this: > > I have a table with 94 fields and a select with only one resultset in only > one client consumes about 0.86 seconds. > The client executes three 'select' statements to perform the task which > consumes 2.58 seconds. > With only one client this is acceptable, but the real problem is as i add > more clients, it goes more and more slower. > > for a single select with one field in one resultset, is 0.86 seconds > normal? > > I tried vacuuming and reindexing but to no avail. > the total record count in that particular table is 456,541. returning 450k rows in around 1 second is about right for a result set with one field. imo, your best bet is to try and break up your table and reorganize it so you dont have to query the whole thing every time. why do you need to return all the rows over and over? merlin
Hi, Amir, AMIR FRANCO D. JOVEN wrote: > My current project uses PostgreSQL 7.3.4. By all means, please upgrade. The newest 7.3 series version is 7.3.16, which fixes lots of critical bugs, and can be used as a drop-in replacement for 7.3.4 (see Release Notes at http://www.postgresql.org/docs/7.3/interactive/release.html ) The newest stable release is 8.1.5, and 8.2 is just on the roads... > I have a table with 94 fields and a select with only one resultset in > only one client consumes about 0.86 seconds. "with only on resultset"? You mean "with only one returned row", I presume. Each SELECT has exactly one resultset, which can contain zero to many rows. Please check the following: - Did you create the appropriate indices? - Version 7.3.X may suffer from index bloat, so REINDEX might help. - Did you VACUUM and ANALYZE the table properly? - Is your free space map setting, the statistics targets, and other config options tuned to fit your environment? - Maybe a VACUUM FULL or a CLUSTER command may help you. > for a single select with one field in one resultset, is 0.86 seconds normal? That depends on the circumstances. Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org
Hi Markus,
Thank you very much for the information.
I was able to make it fast by correcting indices, i created index on frequently filtered fields.
now it runs at 0.05 seconds average, much faster than before 0.86.
I will also upgrade to 8.1.5.
Once again, thank you very much. it helped me a lot.
Amir
--
AMIR FRANCO D. JOVEN
Software Engineer
DIGI Software (PHILS.) Inc.
Thank you very much for the information.
I was able to make it fast by correcting indices, i created index on frequently filtered fields.
now it runs at 0.05 seconds average, much faster than before 0.86.
I will also upgrade to 8.1.5.
Once again, thank you very much. it helped me a lot.
Amir
On 11/15/06, Markus Schaber <schabi@logix-tt.com> wrote:
Hi, Amir,
AMIR FRANCO D. JOVEN wrote:
> My current project uses PostgreSQL 7.3.4.
By all means, please upgrade.
The newest 7.3 series version is 7.3.16, which fixes lots of critical
bugs, and can be used as a drop-in replacement for 7.3.4 (see Release
Notes at http://www.postgresql.org/docs/7.3/interactive/release.html )
The newest stable release is 8.1.5, and 8.2 is just on the roads...
> I have a table with 94 fields and a select with only one resultset in
> only one client consumes about 0.86 seconds.
"with only on resultset"?
You mean "with only one returned row", I presume.
Each SELECT has exactly one resultset, which can contain zero to many rows.
Please check the following:
- Did you create the appropriate indices?
- Version 7.3.X may suffer from index bloat, so REINDEX might help.
- Did you VACUUM and ANALYZE the table properly?
- Is your free space map setting, the statistics targets, and other
config options tuned to fit your environment?
- Maybe a VACUUM FULL or a CLUSTER command may help you.
> for a single select with one field in one resultset, is 0.86 seconds normal?
That depends on the circumstances.
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org
--
AMIR FRANCO D. JOVEN
Software Engineer
DIGI Software (PHILS.) Inc.