Partitioning by status? - Mailing list pgsql-performance

From Mike Blackwell
Subject Partitioning by status?
Date
Msg-id CANPAkgt9mGoF7SyA_n7jX3t6siLGPyA=d1tR2bPwKiAex3bDMQ@mail.gmail.com
Whole thread Raw
Responses Re: Partitioning by status?
Re: Partitioning by status?
List pgsql-performance
We have a set of large tables.  One of the columns is a status indicator (active / archived).  The queries against these tables almost always include the status, so partitioning against that seems to makes sense from a logical standpoint, especially given most of the data is "archived" and most of the processes want active records.

Is it practical to partition on the status column and, eg, use triggers to move a row between the two partitions when status is updated?  Any surprises to watch for, given the status column is actually NULL for active data and contains a value when archived?

Mike

pgsql-performance by date:

Previous
From: darklow
Date:
Subject: Query planner doesn't use index scan on tsvector GIN index if LIMIT is specified
Next
From: Tom Lane
Date:
Subject: Re: Query planner doesn't use index scan on tsvector GIN index if LIMIT is specifiedQuery planner doesn't use index scan on tsvector GIN index if LIMIT is specified