Just to dig up an old thread from last month:
In case anyone was wondering we finally got a free day to put in the new
version of the software, and it's greatly improved the performance. The
solutions we employed were as follows:
- recompile everything with ecpg -t for auto-commit
- vacuum run b
Hi all,
> No wonder, considering that your "less than 10 rows" table contains
> something upwards of 10 tuples:
>
> > INFO: --Relation public.plc_fldio--
> > INFO: Pages 1221: Changed 3, reaped 256, Empty 0, New 0; Tup 108137: Vac
> > 4176, Keep/VTL 108133/108133, UnUsed 19, MinLen 84, MaxL
Hi,
> > Our application requires a number of processes to select and update rows
> > from a very small (<10 rows) Postgres table on a regular and frequent
> > basis. These processes often run for weeks at a time, but over the
> > space of a few days we find that updates start getting painfully sl
Hi,
Our application requires a number of processes to select and update rows
from a very small (<10 rows) Postgres table on a regular and frequent
basis. These processes often run for weeks at a time, but over the
space of a few days we find that updates start getting painfully slow.
We are runni
