Hi,
Thank you all for your help.
@Jeff : my daemon creates these tables at start time so it doesn't do anything
else at the same time. The CPU is loaded between 20% and 25%.
@Richard : Sure the DB number of table is quite big and sure most of them have
the same structure, but it's very har
>Right now, UNION DISTINCT, along with INTERSECT and EXCEPT, have basically no
>optimization support whatsoever...
> Sorry to be the bearer of bad news, but this isn't going to change just
> because you try to label it a bug.
Given the medium, I'll try not to read that in a snarky tone, after al
Nate Allan writes:
> 2) Why would more effort go into Union All rather than Union?
The UNION ALL case matches up with, and shares planning and execution
code with, table-inheritance and partitioning scenarios. So yes, it
really is more interesting to more people than UNION DISTINCT.
(IIRC, the c
>>Nate Allan writes:
>> It seems to me that the join condition (and hence the restriction) should be
>> pushed down into both sides of the union to bring the cardinality limit from
>> millions to 1. I'm imagining a rewrite like this:
>> R(a) J (b U c) -> (b J R(a)) U (c J R(a)) ...wher
Nate Allan writes:
> It seems to me that the join condition (and hence the restriction) should be
> pushed down into both sides of the union to bring the cardinality limit from
> millions to 1. I'm imagining a rewrite like this:
> R(a) J (b U c) -> (b J R(a)) U (c J R(a))
> ...where R
>you are using EAV schema - it is against to relation model enough :)
>this schema has the most terrible performance for large datasets - looks on
>hstore instead
>Pavel
Actually despite the table named Attribute, I am not doing EAV though I can see
why you'd think that. Attributes are part of
