Re: Sorted union - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: Sorted union
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB3417DD79E@Herge.rcsinc.local
Whole thread Raw
In response to Sorted union  (Scott Lamb <slamb@slamb.org>)
Responses Re: Sorted union  (Scott Lamb <slamb@slamb.org>)
List pgsql-performance
> Wow. I hadn't known about generate_series, but there are a bunch of
> places I've needed it.

It's a wonder tool :).

> But I think there is something I can do: I can just do a query of the
> transaction table sorted by start time. My graph tool can keep a

Reading the previous paragraphs I was just about to suggest this.  This
is a much more elegant method...you are reaping the benefits of having
normalized your working set.  You were trying to denormalize it back to
what you were used to.  Yes, now you can drop your index and simplify
your queries...normalized data is always more 'natural'.

> Mind you, I still think PostgreSQL should be able to perform that
> sorted union fast. Maybe sometime I'll have enough free time to take
> my first plunge into looking at a database query planner.

I'm not so sure I agree, by using union you were basically pulling two
independent sets (even if they were from the same table) that needed to
be ordered.  There is zero chance of using the index here for ordering
because you are ordering a different set than the one being indexed.
Had I not been able to talk you out of de-normalizing your table I was
going to suggest rigging up a materialized view and indexing that:

http://jonathangardner.net/PostgreSQL/materialized_views/matviews.html

Merlin

pgsql-performance by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: insert performance for win32
Next
From: "Kevin Grittner"
Date:
Subject: Re: Sorted union