Skip site navigation (1) Skip section navigation (2)

Re: horizontal partition

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Klint Gore <kg(at)kgb(dot)une(dot)edu(dot)au>
Cc: Gaetano Mendola <mendola(at)bigfoot(dot)com>,pgsql-performance(at)postgresql(dot)org
Subject: Re: horizontal partition
Date: 2005-02-03 06:41:57
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance

> This is how I interpret it (if anyone wants to set me straight or
> improve on it feel free)
> Views are implemented as rules.
> Rules are pretty much just a macro to the query builder.  When it sees
> the view, it replaces it with the implementation of the view.

Right so far.

> When you join a view to a table, it generates a subselect of the
> implementation and joins that to the other table.

More or less.   A join set and a subselect are not really different in the 

> So the subselect will generate the entire set of data from the view
> before it can use the join to eliminate rows.

Well, not exactly.  That's what's happening in THIS query, but it doesn't 
happen in most queries, no matter how many view levels you nest (well, up to 
the number FROM_COLLAPSE_LIMIT, anyway).

The issue here is that the planner is capable of "pushing down" the WHERE 
criteria into the first view, but not into the second, "nested" view, and so 
postgres materializes the UNIONed data set before perfoming the join.

Thing is, I seem to recall that this particular issue was something Tom fixed 
a while ago.  Which is why I wanted to know what version Gaetano is using.

Josh Berkus
Aglio Database Solutions
San Francisco

In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2005-02-03 06:55:28
Subject: Re: horizontal partition
Previous:From: Tom LaneDate: 2005-02-03 05:26:16
Subject: Re: GiST indexes and concurrency (tsearch2)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group