On 09/05/2013 05:50 PM, Tom Lane wrote:
Brian Fehrle writes:
I have a view, that when created with our create statement works
wonderfully, a query on the view with a standard where clause that
narrows the result to a single row performs in under a single ms.
However, when we export this view an
Good Afternoon,
I also came across this too.
The issue goes away if you keep your join columns the same data type on
both tables.
The nested loop happens when the join columns are not the same data type.
Hope this helps.
Best
-Mark
On Fri, Sep 6, 2013 at 2:35 PM, Tom Lane wrote:
> Brian Fehrl
*Sorry correction.
I meant the Materialize disappears when the join columns are the same data
type.
On Fri, Sep 6, 2013 at 3:46 PM, Mark Mayo wrote:
> Good Afternoon,
>
> I also came across this too.
> The issue goes away if you keep your join columns the same data type on
> both tables.
> The
Brian Fehrle writes:
> On 09/05/2013 05:50 PM, Tom Lane wrote:
>> I rather doubt that the now-explicit-instead-of-implicit casts have much
>> to do with that. It seems more likely that you forgot to re-ANALYZE in
>> the new database, or there are some different planner settings, or
>> something a
Dear All,
I'm dealing with restore 3 DB at the same time. Previously this task was
sequential but we need to make shorter as possible our daily maintenance window.
Is this possible from your point of view to restore on the same server more
than 1 DB at time? I havwn't found any clear answer on t
Hi again, my mistake. I have found why there are not this optimization (thus I
have found other one, correct, see bellow). I can have for example:
stocktaking_id | stat_item_start
abc | 2013-01-01
abc | 2013-08-08
And when ap
Hi. I have one query which possibly is not optimized by planner (not using
index for aggregate having clause restriction):
explain
SELECT stocktaking_id
FROM t_weighting
GROUP BY stocktaking_id
HAVING MIN(stat_item_start) BETWEEN '2013-08-01' AND '2013-09-01';
with result:
"HashAggregate (cost=
