>
> From: Shaun Thomas
> Date: Tuesday, 10 June 2014 22:07
> So here's the thing. The Linux page reclamation code is *extremely
> broken* in everything before 3.11. Take a look at this, then realize
> that this is *only one patch* from several that target the memory
> manager weightings:
>
>
>
>
> Yeah, it's not expected that that's going to cost much. I am suspicious
> that what you are looking at is mostly measurement overhead: during
> EXPLAIN ANALYZE, each plan node has to do two gettimeofday() calls per
> call, and there are lots of platforms where that is significant relative
>
>
> From: Claudio Freire
>> I thought I would see what happens when I do this:
>>
>>SELECT * FROM ONLY table_a UNION SELECT * FROM table_b;
>>
>>
>>
> What's the point, in the context of this example?
>
> The sort-unique still has to be performed even if you didn't have data
> in on
Hi all,
So I was thinking about the following, after experimenting with constraint
exclusion.
I thought I would see what happens when I do this:
SELECT * FROM ONLY table_a UNION SELECT * FROM table_b;
I noticed that despite table_a still having no data in it, the planner has
already decided
Hi all,
First some background.
I have inherited a system that appears to have a lot of logic built into
views upon views upon views (and then some more views for good measure).
It struck me that the CASE conditions built into those views are causing
poorer performance than expected – so I thought
the difference in execution time becomes
less of a problem at this size.
Tim
From: Tom Lane
Date: Monday, 12 May 2014 12:23
To: Tim Kane
Cc: "pgsql-performance@postgresql.org"
Subject: Re: [PERFORM] 9.2.4 vs 9.3.0 query planning (sort merge join vs
hash join)
Tim Kane writes:
&
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
