On Mon, 15 Sep 2003 22:26:45 -0400, Christopher Browne
[EMAIL PROTECTED] wrote:
select count (*) from table;
The only possible plan for THAT query will involve a seq scan of the
whole table. If the postmaster already has the data in cache, it
makes sense for it to run in 1 second. If it has to
...
#effective_cache_size = 1000# typically 8KB each
That's horribly wrong. It's telling PG that your OS is only likely to cache
8MB of the DB in RAM. If you've got 1GB of memory it should be between
64000 and 96000
---(end of
Dear list,
First and foremost, thanks to the great number of people who have responded
with various tips and suggestions. I am now starting to fully appreciate
the various cache settings and what they can do for performance.
I just want to redefine the problem based on the knowledge of it that
On Tue, 16 Sep 2003, Joseph Bove wrote:
I still think that 3 seconds is not acceptable. However, I reserve the
right to be wrong. Does it sound unrealistic to expect PostgreSQL to be
able to read 90,000 rows with 300 bytes per row in under a second?
first, check to see what your max
To whoever can assist,
I am working with a decent sized database on an extremely powerful machine.
The specs follow:
OS: RedHat Linux 9.0
PG Version 7.3
Memory 1 gig
CPU Quad Processor - Unsure of
On Mon, 15 Sep 2003, Joseph Bove wrote:
I am working with a decent sized database on an extremely powerful machine.
The specs follow:
OS: RedHat Linux 9.0
PG Version 7.3
Memory 1 gig
CPU Quad Processor -
On Mon, Sep 15, 2003 at 17:34:12 -0400,
Joseph Bove [EMAIL PROTECTED] wrote:
I do a rather simple query: select count (*) from large-table where column
= some value;
About 80% of the time, the response time is sub-second. However, at 10% of
the time, the response time is 5 - 10
Joseph,
Please see this web page before posting anything else:
http://techdocs.postgresql.org/guides/SlowQueryPostingGuidelines
Currently, you are not posting enough data for anyone to be of meaningful
help.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
On Mon, 15 Sep 2003, Joseph Bove wrote:
Stephan,
Actually, it's inconsistent with the exact same command. I've now
replicated the problem by doing the following command:
select count (*) from table;
The table in question has 88899 rows.
The response time is anywhere from 1 second to 12
Stephan,
I've run explain analyze a number of times and have gotten results between
5.5 and 7.5 seconds
Attached is a typical output
QUERY PLAN
-
Aggregate (cost=9993.92..9993.92 rows=1 width=0)
(actual time=7575.59..7575.59 rows=1
[EMAIL PROTECTED] (Joseph Bove) writes:
I do a rather simple query: select count (*) from large-table where
column = some value;
About 80% of the time, the response time is sub-second. However, at
10% of the time, the response time is 5 - 10 seconds.
Does it seem data-dependent?
That is,
On Mon, 15 Sep 2003, Joseph Bove wrote:
Stephan,
I've run explain analyze a number of times and have gotten results between
5.5 and 7.5 seconds
Attached is a typical output
QUERY PLAN
-
Aggregate (cost=9993.92..9993.92 rows=1 width=0)
it seems like the difference is probably related to caching. you say
you have 1gb of ram, and the database is 2gb.Obviously the entire
database isn't cached, but maybe your query runs fast when the table is
in memory, and they it gets swapped out of cache because some other
piece of
On Mon, 15 Sep 2003, scott.marlowe wrote:
On Mon, 15 Sep 2003, Joseph Bove wrote:
Stephan,
I've run explain analyze a number of times and have gotten results between
5.5 and 7.5 seconds
Attached is a typical output
QUERY PLAN
-
The world rejoiced as [EMAIL PROTECTED] (Joseph Bove) wrote:
Actually, it's inconsistent with the exact same command. I've now
replicated the problem by doing the following command:
select count (*) from table;
The table in question has 88899 rows.
The response time is anywhere from 1
15 matches
Mail list logo
