Robert James wrote:
> What information would be helpful to post?
That question comes up so often we have a page to help answer it. :-)
http://wiki.postgresql.org/wiki/SlowQueryQuestions
-Kevin
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subs
Robert James writes:
> On 1/18/13, Tom Lane wrote:
>> Whether that's the explanation is of course impossible to know from
>> the given (lack of) information.
> What information would be helpful to post?
Both forms of the query, EXPLAIN ANALYZE output for both, along with the
underlying table de
On 1/18/13, Tom Lane wrote:
> Jeff Janes writes:
>> On Fri, Jan 18, 2013 at 9:29 AM, Robert James
>> wrote:
>>> In other words: Since my query is 100% identical algebraicly to not
>>> using a temp table, why is it so much faster? Why can't the planner
>>> work in the exact same order?
>
>> Unles
Jeff Janes writes:
> On Fri, Jan 18, 2013 at 9:29 AM, Robert James wrote:
>> In other words: Since my query is 100% identical algebraicly to not
>> using a temp table, why is it so much faster? Why can't the planner
>> work in the exact same order?
> Unless you are doing ANALYZE on your temp tab
On Fri, Jan 18, 2013 at 9:29 AM, Robert James wrote:
> I'd like to understand better why manually using a temp table can
> improve performance so much.
>
> I had one complicated query that performed well. I replaced a table
> in it with a reference to a view, which was really just the table with
Hello
2013/1/18 Robert James :
> I'd like to understand better why manually using a temp table can
> improve performance so much.
one possible effect - there should be different statistic
did you look on EXPLAIN ANALYZE?
Regards
Pavel Stehule
>
> I had one complicated query that performed wel
I'd like to understand better why manually using a temp table can
improve performance so much.
I had one complicated query that performed well. I replaced a table
in it with a reference to a view, which was really just the table with
an inner join, and performance worsened by 2000x. Literally.