Tom,
After almost 20 hours running vacuum I see postmaster grew a little bit:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
20458 postgres 15 0 2136m 553m 204m D 33.2 54.7 198:18.36 postmaster
It's strange that I see no output since starting
vacuumdb -v -z -f wsdb > vac
On Fri, 28 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
Memory growth stoped at 1.8Gb
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
20458 postgres 15 0 1902m 503m 204m D 5.9 49.7 13:59.61 postmaster
Index-related memory leak maybe? What are the indexes on this tab
Oleg Bartunov writes:
> Memory growth stoped at 1.8Gb
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 20458 postgres 15 0 1902m 503m 204m D 5.9 49.7 13:59.61 postmaster
Index-related memory leak maybe? What are the indexes on this table,
exactly?
On Fri, 28 Jan 2005, Oleg Bartunov wrote:
On Thu, 27 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
Day ago we run 'vacuum verbose analyze;' and now we're observing
strange output (see below). We see many repeated passes through the
table 'usno' and all indices (2).
Nothing strange about it: that
On Thu, 27 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
Day ago we run 'vacuum verbose analyze;' and now we're observing
strange output (see below). We see many repeated passes through the
table 'usno' and all indices (2).
Nothing strange about it: that's how vacuum deals with large tables.
You
Oleg Bartunov writes:
> Day ago we run 'vacuum verbose analyze;' and now we're observing
> strange output (see below). We see many repeated passes through the
> table 'usno' and all indices (2).
Nothing strange about it: that's how vacuum deals with large tables.
You can reduce the number of pass
Hi there,
we have a table with 500mln rows:
wsdb=# \d usno
Table "public.usno"
Column | Type | Modifiers
++---
ra | real |
dec| real |
bmag | real |
rmag | real |
ipix | bigint |
Indexes:
"ipix_ind" btree (ipix)
"radec_idx1" btree
