> I have a query that takes 2 sec if I run it from a freshly restored dump.
> If I run a full vacuum on the database it then takes 30 seconds.
What do the two plans look like? Can you post the explains?
-Nathan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make chang
Thanks for the advice. I will keep playing with it. Can someone here
comment on EnterpriseDB or another companies paid support? I may
consider this to quickly improve my performance.
Scott Marlowe wrote:
Have you run analyze on the tables? bumped up default stats and re-run analyze?
Best way
Oh, another point of attack. Always test your queries under just
\timing. You can wrap up like this:
\timing
select count(*) from (subselect goes here);
I've been on a few machines where the cost of explain analyze itself
threw the timing way off.
--
Sent via pgsql-general mailing list (pgsql
Have you run analyze on the tables? bumped up default stats and re-run analyze?
Best way to send query plans is as attachments btw.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I have a query that takes 2 sec if I run it from a freshly restored
dump. If I run a full vacuum on the database it then takes 30 seconds.
Would someone please comment as to why I would see a 15x slow down by
only vacuuming the DB?
I am using 8.3.1
--
Sent via pgsql-general mailing list (pg
Jason Long wrote:
> I would greatly appreciate any advice on how to read the following
> output from EXPLAIN ANALYZE.
>
> When running the query the first time from a fresh restore it takes
> about 55 sec.
> On a second run is take about 2 sec.
> After the vacuum it takes about 36 sec no matter
I am resending this is plain text as it was rejected. What is the best
way to include this kind of output to the mailing list?
I would greatly appreciate any advice on how to read the following
output from EXPLAIN ANALYZE.
When running the query the first time from a fresh restore it takes
Just post the explain analyze output here on the list. There's lots
of folks here who can read it.
On Wed, Jun 4, 2008 at 5:49 PM, Jason Long
<[EMAIL PROTECTED]> wrote:
> Yes.
> This is what I do.
> 1. Vacuum full
> 2. Reindex force
> This is done ever night
>
> My users complained about a report
Yes.
This is what I do.
1. Vacuum full
2. Reindex force
This is done ever night
My users complained about a report being slow.
I grabbed a dump and restored it to my development machine.
The query worked just fine, but not on the production server.
I did a vacuum full and then reran the q
Jason Long <[EMAIL PROTECTED]> writes:
> I have a query that takes 2 sec if I run it from a freshly restored
> dump. If I run a full vacuum on the database it then takes 30 seconds.
> Would someone please comment as to why I would see a 15x slow down by
> only vacuuming the DB?
EXPLAIN ANALYZE o
On Wed, 2008-06-04 at 17:02 -0500, Jason Long wrote:
> I have a query that takes 2 sec if I run it from a freshly restored
> dump. If I run a full vacuum on the database it then takes 30 seconds.
If you run it a second time after the vacuum full?
Joshua D. Drake
--
Sent via pgsql-general m
I have a query that takes 2 sec if I run it from a freshly restored
dump. If I run a full vacuum on the database it then takes 30 seconds.
Would someone please comment as to why I would see a 15x slow down by
only vacuuming the DB? Reindexing does not help, and a full vacuum was
run just prior
12 matches
Mail list logo
