Re: vacuum vs vacuum full

From: Ron <ronljohnsonjr(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: vacuum vs vacuum full
Date: 2020-11-18 16:45:30
Message-ID: 734e6c91-8cf9-008a-5f49-1061478e12e3@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 11/18/20 6:02 AM, Laurenz Albe wrote:
> On Wed, 2020-11-18 at 10:57 +0100, Thomas Kellerer wrote:
>>> No matter how long it takes, this is an excellent argument for
>>> partitioning Very Large Tables: many maintenance tasks are made
>>> *much* easier.
>> The problem is, you can't partition every table as long as Postgres
>> does not support a primary key that is independent of the partitioning key
>> (i.e. until it has "global indexes" as they are called in Oracle)
> I personally hope that we will never have global indexes.
> I am not looking forward to helping customers with the problems that
> they create (long duration of ATTACH/DETACH PARTITION, index fragmentation).

I've been using what Oracle calls "global indexes" for 20 years. They're
super useful when -- for example -- you want to partition a transaction
table by a date field, while the PK is synthetic.

Up until about two years ago, I purged old data every six months. (Then it
was migrated from the legacy RDBMS to Oracle.)

Yes, you've got to drop and rebuild the indices, but that's a small price to
pay for the simplicity of archiving (especially when the indices are built
in parallel).

--
Angular momentum makes the world go 'round.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Snjezana Frketic 2020-11-18 16:56:26 Re: How to select values in a JSON type of column?
Previous Message David G. Johnston 2020-11-18 16:36:06 Re: psql backward compatibility