Hello everyone.
We are facing a performance problem with views consisting of several
unioned tables. The simplified schema is as follows:
CREATE TABLE foo (
foo_object_id bigint,
link_id bigint,
somedatatext,
PRIMARY KEY (foo_object_id) );
Michal Taborsky wrote:
...
UNION
...
The result is sequential scan on all tables, append, sort and then
filter scan on this whole thing. Which of course is slow as hell. We use
version 8.0.2.
And now the question: Is there a way to force the planner to push the
condition lower, so it will
Hello everyone.
We are facing a performance problem with views consisting of several
unioned tables. The simplified schema is as follows:
CREATE TABLE foo (
foo_object_id bigint,
link_id bigint,
somedatatext,
PRIMARY KEY (foo_object_id) );
On Fri, Nov 04, 2005 at 12:38:30PM +0100, Michal Taborsky wrote:
SELECT object_id FROM commonview WHERE link_id=1234567
The result is sequential scan on all tables, append, sort and then
filter scan on this whole thing. Which of course is slow as hell. We use
version 8.0.2.
I couldn't
Michal Taborsky [EMAIL PROTECTED] writes:
We are facing a performance problem with views consisting of several
unioned tables. The simplified schema is as follows:
Perhaps you should show us the real schema, because I cannot duplicate
your complaint on the toy case you show.
regression=#
Tom Lane napsal(a):
Michal Taborsky [EMAIL PROTECTED] writes:
We are facing a performance problem with views consisting of several
unioned tables. The simplified schema is as follows:
Perhaps you should show us the real schema, because I cannot duplicate
your complaint on the toy case you
Michal Taborsky [EMAIL PROTECTED] writes:
OK. Mystery (sort of) solved. After you told me it works for you I had
to assume the problem was somewhere else. And, indeed, it was, though
it's not too obvious.
The two attributes are actually not of tybe bigint, but of type
crm_object_id, which
