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 throug
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
...
> #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 broadcast)-
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 h
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
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
> > -
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 infor
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
[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
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 loops=
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 sec
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
---
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 seconds. Different
response times can occur in
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
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 Proces
15 matches
Mail list logo