Re: [PERFORM] Join vs Subquery

2007-05-03 Thread Tom Lane
Brian Herlihy <[EMAIL PROTECTED]> writes: > The issue: the second query results in a lower cost estimate. I am wondering > why the second query plan was not chosen for the first query. 8.1 is incapable of pushing indexable join conditions down below an Append. Try 8.2. r

Re: [PERFORM] Join vs Subquery

2007-05-03 Thread Gregory Stark
"Brian Herlihy" <[EMAIL PROTECTED]> writes: > There is a unique index mapping domains to domain_ids. ... > The issue: the second query results in a lower cost estimate. I am wondering > why the second query plan was not chosen for the first query. Well the unique index you mentioned is critical t

[PERFORM] Join vs Subquery

2007-05-02 Thread Brian Herlihy
Hi, I am using postgres 8.1.3 for this. If this has been dealt with later, please disregard. And this is not a complaint or a request, I am just curious, so I know how to best construct my queries. There is a unique index mapping domains to domain_ids. views_ts specifies a partitioned table,

[PERFORM] join vs. subquery

2005-02-22 Thread David Haas
Hi - This is based on a discussion I was having with neilc on IRC. He suggested I post it here. Sorry for the length - I'm including everything he requested. I'm comparing the speeds of the following two queries. I was curious why query 1 was faster than query 2: query 1: Select layer_nu