On Tue, 1 Feb 2005, Tom Lane wrote:
Oleg Bartunov writes:
I see that pgsql_tmp/ contains files, looks like clustered table.
What postmaster is doing if disk usage doesn't changed ?
Most likely doing a disk-based merge sort ...
so, it uses 'work_mem' as a buffer ?
regards,
On Tue, 1 Feb 2005, Tom Lane wrote:
Oleg Bartunov writes:
I see that pgsql_tmp/ contains files, looks like clustered table.
What postmaster is doing if disk usage doesn't changed ?
Most likely doing a disk-based merge sort ...
just interesting - multiway, in-place or just place merge sort ?
Oleg Bartunov writes:
> I see that pgsql_tmp/ contains files, looks like clustered table.
> What postmaster is doing if disk usage doesn't changed ?
Most likely doing a disk-based merge sort ...
regards, tom lane
---(end of broadcast)-
On Sun, 30 Jan 2005, Oleg Bartunov wrote:
Seems, postmaster eats expected amount of memory now ! Will see how long
it will proceeded. Probably, my case should be documented somewhere.
just to inform - vacuum took almost 48 hours !
Another possibility is to use CLUSTER or a rewriting ALTER TABLE t
On Sun, 30 Jan 2005, Oleg Bartunov wrote:
On Sun, 30 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
On Sun, 30 Jan 2005, Tom Lane wrote:
I'm confused. The log trace you showed us before appeared to be from
a non-FULL vacuum, but here you're saying it's VACUUM FULL. Which is
it ... or did you ch
On Sun, 30 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
On Sun, 30 Jan 2005, Tom Lane wrote:
I'm confused. The log trace you showed us before appeared to be from
a non-FULL vacuum, but here you're saying it's VACUUM FULL. Which is
it ... or did you change?
Yes, first time I tried vacuum from
Oleg Bartunov writes:
> On Sun, 30 Jan 2005, Tom Lane wrote:
>> I'm confused. The log trace you showed us before appeared to be from
>> a non-FULL vacuum, but here you're saying it's VACUUM FULL. Which is
>> it ... or did you change?
> Yes, first time I tried vacuum from withing psql, next time
On Sun, 30 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
I tried run 'vacuumdb -v -z -f wsdb > vacuum-wsdb.log 2>&1&'
I'm confused. The log trace you showed us before appeared to be from
a non-FULL vacuum, but here you're saying it's VACUUM FULL. Which is
it ... or did you change?
Yes, first t
Oleg Bartunov writes:
> I tried run 'vacuumdb -v -z -f wsdb > vacuum-wsdb.log 2>&1&'
I'm confused. The log trace you showed us before appeared to be from
a non-FULL vacuum, but here you're saying it's VACUUM FULL. Which is
it ... or did you change?
regards, tom lane
-
