"Luiz K. Matsumura" writes:
> If we run the commands "vacumm full analyze"
If you're using the cost based vacuum delay, don't forget that it
will probably take long; possibly, you may deactivate it locally
before running VACUUM FULL, in case the locked table is mandatory
for your running applica
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 22 Jan 2008 17:44:33 -0200
"Luiz K. Matsumura" <[EMAIL PROTECTED]> wrote:
> >
>
> Joshua D. Drake wrote:Hi,
>
> If we run the commands "vacumm full analyze" and "reindex table",
> this can be considered as equivalent to making a dump / resto
Adam PAPAI wrote:
Hi pgsql-performance,
I've a problem with the select * on a small table.
See below:
x7=# SELECT count(idn) from megjelenesek;
count
---
162
(1 row)
Why does it take cca 18-20 sec to get the results?
Too many indexes?
You likely have a huge amount of dead rows. T
Adam PAPAI <[EMAIL PROTECTED]> wrote ..
> Hi pgsql-performance,
>
> I've a problem with the select * on a small table.
>
I can think of two possibilities for such incredibly slow performance.
One: your table has not been VACUUMed for a long time and is full of dead
tuples. Try VACUUM FULL on i
On Sun, Dec 16, 2007 at 07:34:45PM +0100, Adam PAPAI wrote:
> Why does it take cca 18-20 sec to get the results?
> Too many indexes?
You cannot possibly have VACUUMed in a long time. Try a VACUUM FULL, and then
schedule regular VACUUMs (or use autovacuum).
/* Steinar */
--
Homepage: http://www.s
Adam PAPAI wrote:
Hi pgsql-performance,
I've a problem with the select * on a small table.
See below:
x7=# SELECT count(idn) from megjelenesek;
count
---
162
(1 row)
Why does it take cca 18-20 sec to get the results?
Too many indexes?
You likely have a huge amount of dead rows. Try
Hi pgsql-performance,
I've a problem with the select * on a small table.
See below:
x7=# EXPLAIN ANALYZE select * from megjelenesek;
QUERY PLAN
