I re-ran the query in multiple forms, and included it below (I regexed it to
become 'foo2bar' so it's more generic to others).
I also uploaded it as a public spreadsheet to google, because I think that is a
bit easier to look at:
https://docs.google.com/spreadsheets/d/1w9HM8w9YUpu
On Nov 18, 2014, at 6:43 PM, Tom Lane wrote:
> but as for why it gets a much worse plan after
> flattening --- insufficient data.
Thanks. I'll run some test cases in the morning and post the full queries
matched with ANALYZE EXPLAIN.
This is just puzzling to me. I was hoping there might be a
Jonathan Vanasco-7 wrote
> I have a particular query that returns resultset of 45k rows out of a
> large resultset (pg 9.3 and 9.1)
>
> It's a many 2 many query, where I"m trying to search for Bar based on
> attributes in a linked Foo.
>
> I tweaked the indexes, optimized the query, and got it do
Jonathan Vanasco writes:
> This is what I don't understand -- notice the two order_by calls.
> If i run this with an inner and outer order_by, I get ~305ms. (I don't
> think I need both, but I wasn't sure if ordering is kept from a subselect )
> If i run this with only the inner,
I have a particular query that returns resultset of 45k rows out of a large
resultset (pg 9.3 and 9.1)
It's a many 2 many query, where I"m trying to search for Bar based on
attributes in a linked Foo.
I tweaked the indexes, optimized the query, and got it down an acceptable speed
around 1,100m
