Pailloncy Jean-Gerard <[EMAIL PROTECTED]> writes:
> Update to my case:
> I drop and recreate the index and there was no problem this time.
> Strange...
Well, that time there wasn't actually any work for VACUUM FULL to do.
I think the bloat is probably driven by having to move a lot of rows
in orde
Update to my case:
I drop and recreate the index and there was no problem this time.
Strange...
# DROP INDEX pkpoai.test_metadata_all;
DROP INDEX
# VACUUM FULL VERBOSE ANALYZE pkpoai.metadata;
INFO: vacuuming "pkpoai.metadata"
INFO: "metadata": found 167381 removable, 3133397 nonremovable row
ve
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> This looks like it must be a memory leak in the gist indexing code
>> (either gist itself or tsearch2). I don't see any post-release fixes in
>> the 7.4 branch that look like they fixed any such thing :-(, so it's
On Fri, Dec 17, 2004 at 14:46:57 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> This looks like it must be a memory leak in the gist indexing code
> (either gist itself or tsearch2). I don't see any post-release fixes in
> the 7.4 branch that look like they fixed any such thing :-(, so it's
> p
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Jean-Gerard, can you put together a self-contained test case? I suspect
>> it need only look like "put some data in a table, make a tsearch2 index,
>> delete half the rows in the table, VACUUM FULL". But I don't have time
>> to try to cons up a test case r
Tom,
> Jean-Gerard, can you put together a self-contained test case? ÂI suspect
> it need only look like "put some data in a table, make a tsearch2 index,
> delete half the rows in the table, VACUUM FULL". ÂBut I don't have time
> to try to cons up a test case right now, and especially not to figu
Josh Berkus <[EMAIL PROTECTED]> writes:
> Jean-Gerard,
>> When backend hits the tsearch2 index, SIZE/RES grows until it reachs
>> 1GB, where I got the error.
>> PIDUID PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
>> 20461503-50 765M 824M sleep biowai 4:26 33.20% pos
Jean-Gerard,
> The classic output from top (during all other index vacuum):
>PIDUID PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
> 20461503140 13M 75M sleep semwai 5:27 2.05% postgres
>
> When backend hits the tsearch2 index, SIZE/RES grows until it reachs
>
The classic output from top (during all other index vacuum):
PIDUID PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
20461503140 13M 75M sleep semwai 5:27 2.05% postgres
When backend hits the tsearch2 index, SIZE/RES grows until it reachs
1GB, where I got the erro
I have a table with an tsearch2 full text index on PG 7.4.2. And a
query against the index is really slow.
I try to do a "VACUUM FULL VERBOSE ANALYZE pkpoai.metadata" and I got
an error.
I monitor memory usage with top, and pg backend uses more and more
memory and hits the limit of 1GB of RAM use.
Jean-Gerard,
> I have a table with an tsearch2 full text index on PG 7.4.2. And a
> query against the index is really slow.
> I try to do a "VACUUM FULL VERBOSE ANALYZE pkpoai.metadata" and I got
> an error.
> I monitor memory usage with top, and pg backend uses more and more
> memory and hits the
I have a table with an tsearch2 full text index on PG 7.4.2. And a
query against the index is really slow.
I try to do a "VACUUM FULL VERBOSE ANALYZE pkpoai.metadata" and I got
an error.
I monitor memory usage with top, and pg backend uses more and more
memory and hits the limit of 1GB of RAM us
12 matches
Mail list logo
