vents table, even though this would feel a little bit like a hack.
Any insights would be greatly appreciate.
-- AWG
On Tue, Apr 08, 2014 at 09:55:38AM -0400, Tom Lane wrote:
> "Andrew W. Gibbs" writes:
> > A very common query against this table is of the form...
>
> &g
Your understanding of the utility of multi-part indices does not jive
with my own.
While I agree that a partial index might be in order here, that ought
just be a performance optimization that lowers the footprint of the
index from an index size and index maintenance standpoint, not
something that
I have a fairly large table (~100M rows), let's call it "events", and
among other things it has a couple of columns on it, columns that
we'll call entity_type_id (an integer) and and published_at (a
timestamp). It has, among others, indices on (published_at) and
(entity_type_id, published_at).
A
Postgres Performance Wizards,
I am a few years into developing and operating a system underpinned by
Postgres that sees the arrival a significant number of events around
the clock, not an epic amount of data, but enough to be challenging to
me, in particular when system downtime is not very palata
