vacuum_cost_delay = 100
No idea how long will take normal vacuum. I ll try tonight when there is
not too much load.
That can really take the VACUUM a long time to complete, but you might want
to have it there as it will be good for performance by setting it a little
high in a high OLTP environme
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> You don't have vacuum_cost_delay set, do you? How long does normal
> vacuum run?
vacuum_cost_delay = 100
No idea how long will take normal vacuum. I ll try tonight when there is
not too much load.
>
> The manual suggests dropping all indexes be
The problem seems due to a weird LOCALES setup: the default DB locale was UTF8
while the tables and the client encodig were LATIN9. The index in the
reco_alphanum field had no special operator class defined.
A complete initdb and a reload of everything with the same locale (LATIN9)
fixed the issue
Ruben Rubio wrote:
Vacuum full is very slow for me . I dont know how to speed it up. It
takes between 60 and 90 minutes.
I have set up autovacuum but I also run vacuum full once per week.
Do you really need to run vacuum full? I don't know you're workload, but
usually you're better off just n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Vacuum full is very slow for me . I dont know how to speed it up. It
takes between 60 and 90 minutes.
I have set up autovacuum but I also run vacuum full once per week.
The slowest parts in the vacuum full output are :
INFO: "a": moved 14076 r
On Monday 19 March 2007 05:07 Tom Lane wrote:
> Vincenzo Romano <[EMAIL PROTECTED]> writes:
> > How can I delay the query planner decisions until the actual query is to
> > be done inside the function body?
>
> Use plpgsql's EXECUTE. AFAIR there is no way in a SQL-language function.
>
>
