I have small database. However the following query takes 38 (!) seconds to
run.
How to speed it up (preferably not changing table structures but possibly
creating indexes) ?
Andrus.
set search_path to public,firma1;
explain analyze select bilkaib.summa from BILKAIB join KONTO CRKONTO ON
Andrus [EMAIL PROTECTED] writes:
I have small database. However the following query takes 38 (!) seconds to
run.
How to speed it up (preferably not changing table structures but possibly
creating indexes) ?
ANALYZE would probably help.
- Seq Scan on konto dbkonto
- Seq Scan on konto dbkonto (cost=0.00..23.30
rows=1
width=44) (actual time=0.017..1.390 rows=219 loops=1)
Filter: (iseloom = 'A'::bpchar)
Anytime you see a row estimate that far off about a simple single-column
condition, it means your
Andrus [EMAIL PROTECTED] writes:
I see autovacuum: processing database mydb messages in log file and I have
stats_start_collector = on
stats_row_level = on
in config file. Why statistics was out-of-date ?
The default autovac thresholds are not very aggressive; this table was
probably not
On Mon, May 08, 2006 at 08:03:38PM +0300, Andrus wrote:
The default autovac thresholds are not very aggressive; this table was
probably not large enough to get selected for analysis.
Tom,
thank you.
Excellent.
BTW, you might want to cut all the autovac thresholds in half; that's
what I
BTW, you might want to cut all the autovac thresholds in half; that's
what I typically do.
I added ANALYZE command to my procedure which creates and loads data to
postgres database
from other DBMS. This runs only onvce after installing my application. I
hope this is sufficient.
If default
On Mon, May 08, 2006 at 08:36:42PM +0300, Andrus wrote:
BTW, you might want to cut all the autovac thresholds in half; that's
what I typically do.
I added ANALYZE command to my procedure which creates and loads data to
postgres database
from other DBMS. This runs only onvce after
The only reason for being so conservative that I'm aware of was that it
was a best guess. Everyone I've talked to cuts the defaults down by at
least a factor of 2, sometimes even more.
Can we ask that Tom will change default values to 2 times smaller in 8.1.4 ?
BTW, these parameters are
On Monday 08 May 2006 14:10, Andrus wrote:
The only reason for being so conservative that I'm aware of was that it
was a best guess. Everyone I've talked to cuts the defaults down by at
least a factor of 2, sometimes even more.
Can we ask that Tom will change default values to 2 times
Jan de Visser [EMAIL PROTECTED] writes:
On Monday 08 May 2006 14:10, Andrus wrote:
I created empty table konto and loaded more that 219 records to it during
database creation.
So it seems that if table grows from zero to more than 219 times larger
then it was still not processed.
That's
Tom Lane wrote:
Jan de Visser [EMAIL PROTECTED] writes:
On Monday 08 May 2006 14:10, Andrus wrote:
I created empty table konto and loaded more that 219 records to it during
database creation.
So it seems that if table grows from zero to more than 219 times larger
then it was still not
11 matches
Mail list logo
