On Mon, May 12, 2014 at 4:02 AM, Phan Công Minh wrote:
> Thank you for your response. I check the article (
> http://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/) and
> it seems to work with general process as well.
> However does it have anyway to calculate the memory used by sin
On Mon, May 12, 2014 at 3:45 AM, Tim Kane wrote:
> Hi all,
>
> Is there a propensity for 9.2.4 to prefer a sort-merge-join, in place of a
> hash join?
>
> I’m fairly sure the answer is yes, but I also want to be sure I’m
> interpreting the explain output correctly.
>
> I’m comparing behaviour bet
Hmm. Interesting.
Thanks Tom, it does indeed look like the planner is evaluating and excluding
the hashed-join plan as having a higher cost. I can see this by setting
enable_mergejoin=0.
I think this may play against other aspects of the query (though only
marginally), so I can’t really compare t
Tim Kane writes:
> Is there a propensity for 9.2.4 to prefer a sort-merge-join, in place of a
> hash join?
Not particularly; I don't think there's any actual difference in the cost
estimation equations between 9.2 and 9.3. The two plans you show are
close enough in estimated cost that the orderi
Hi all,
Is there a propensity for 9.2.4 to prefer a sort-merge-join, in place of a
hash join?
I’m fairly sure the answer is yes, but I also want to be sure I’m
interpreting the explain output correctly.
I’m comparing behaviour between two systems, which for all intents and
purposes are identical
Hi Clinton,
Thank you for your response. I check the article
(http://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/) and it
seems to work with general process as well.
However does it have anyway to calculate the memory used by single query, not
the whole postgresql process?
Than
