Vivek Khera <[EMAIL PROTECTED]> writes:
> Restore of a significanly big database (~19.8GB restored) shows nearly
> no time difference depending on sort_mem when checkpoint_segments is
> large. There are quite a number of tables and indexes. The restore
> was done from a pg_dump -Fc dump of one da
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
Vivek,
> And the winner is... checkpoint_segments.
>
> Restore of a significanly big database (~19.8GB restored) shows nearly
> no time difference depending on sort_mem when checkpoint_segments is
> large. There are quite a number of tables and indexes. The restore
> was done from a pg_dump -Fc
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
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 exact
Title: FINALLY A LIP PLUMPER THAT ACTUALLY WORKS !!!
Get Plump, Sexy Lip'sIn Under 30 Days!
visit website
CITY LIP'S exclusive lip treatment...
>
Stimulates collagen & hyaluronic moisture in your lip's resulting in BIGGER, LUSCIOUS, more SENSUOUS Lip's
>
CITY LIP'S is used by men & women
And the winner is... checkpoint_segments.
Restore of a significanly big database (~19.8GB restored) shows nearly
no time difference depending on sort_mem when checkpoint_segments is
large. There are quite a number of tables and indexes. The restore
was done from a pg_dump -Fc dump of one databas
On 10 Sep 2003 at 22:44, Tom Lane wrote:
> James Robinson <[EMAIL PROTECTED]> writes:
> > Is this just a dead end, or is there some variation of this that might
> > possibly work, so that ultimately an undoctored literal number, when
> > applied to an int8 column, could find an index?
>
> I t
17 matches
Mail list logo
