Re: dropping a master table and all of its partitions? - Mailing list pgsql-general

From Tom Lane
Subject Re: dropping a master table and all of its partitions?
Date
Msg-id 20145.1172590775@sss.pgh.pa.us
Whole thread Raw
In response to Re: dropping a master table and all of its partitions?  (George Nychis <gnychis@cmu.edu>)
List pgsql-general
George Nychis <gnychis@cmu.edu> writes:
> Tom Lane wrote:
>> While neither number
>> is exactly awe-inspiring, I'm not seeing why you think the DROP is
>> particularly broken?
>>
> Then maybe it's a bug in my version of postgresql, what version are you using?

I tried it on HEAD and 8.2 and didn't see a problem.  Just now I retried
on 8.1 and indeed it eats memory :-(.  It looks like the immediate
difference is the lack of this 8.2 fix:

2006-01-08 15:04  tgl

    * src/backend/utils/cache/relcache.c: Avoid leaking memory while
    reading toasted entries from pg_rewrite, and nail a couple more
    system indexes into cache.  This doesn't make any difference in
    normal system operation, but when forcing constant cache resets
    it's difficult to get through the rules regression test without
    these changes.

There are quite a few other changes in 8.2 that are likely to help you
if you want to work with large numbers of partitions, so rather than
worrying about whether this change would be safe to back-patch, I'd
suggest an upgrade.  Even with 8.2 though I'm not sure that you will get
decent performance with thousands of partitions.  That infrastructure
is intended for maybe 10 to 100 partitions, not thousands ...

            regards, tom lane

pgsql-general by date:

Previous
From: "David Gagnon"
Date:
Subject: select ARRAY[1,4,3] @> ARRAY[3,1] gives ERROR: operator does not exist: integer[] @> integer[] ???
Next
From: Michael Fuhr
Date:
Subject: Re: Unable to restore dump due to client encoding issues -- or, when is SQL_ASCII really UTF8