Hello,
Le 29/07/09 16:44, Bob Gobeille a écrit :
>
> On Jul 29, 2009, at 8:26 AM, nha wrote:
>
>> Hello,
>>
>> Le 29/07/09 15:02, Jasen Betts a écrit :
>>> On 2009-07-27, Bob Gobeille wrote:
>>>> I would like to combine multiple databases (sam
ged by master db);
-or the master db will reflect a combined view of data hosted by all
other databases (ie. data manipulation would still perform on
distributed databases and master db would play a role of federated view);
-or both (data manipulation have to be manageable at the both side: on
master db
T pr2.roleid, pr2.organisation_id FROM organisation_roles pr2
WHERE pr2.read) pr
LEFT JOIN hasrole phr ON pr.roleid = phr.roleid
) t
ON p.organisation_id = t.organisation_id;
Let you consider if the corresponding query plan looks better.
Regards.
--
nha / Lyon / France.
--
Sent via pgsql-genera
1=x, col2=y WHERE pkID IN (1, 2, 3);
Lists of pkID would rather be expressed in terms of enumeration when in
WHERE clause. In a more general situation, I would recommand to
determine pkIDs list before building UPDATE statement(s) if possible.
This hint would surely save runtime.
With regards.
--
n
Improvements on the merging UPDATE statements may thence be advised if
some pieces of original statements could be given--without compromising
confidential data.
Regards.
--
nha / Lyon / France.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
nt(*) FROM jfoobar
WHERE
keywords && '{ford, toyota, volkswagen, saturn, honda, porsche,
hummer, ferrari}'::text[];
-- form 2: developped text table
SELECT count(*) FROM jfoobar
WHERE
(
keywords && '{ford}'::text[]
OR keywords && '{toyota}'::text[]
OR keywords && '{volkswagen}'::text[]
OR keywords && '{saturn}'::text[]
OR keywords && '{honda}'::text[]
OR keywords && '{porsche}'::text[]
OR keywords && '{hummer}'::text[]
OR keywords && '{ferrari}'::text[]
);
--
The runtime would only depend on the update strategy for the join table.
Regards.
--
nha / Lyon / France.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
overall runtimes, ie. clearly dominating the overall query plan.
In my opinion, analysis and optimization may be deepen over table
indexes used for join planning. As your reported query plans show, the
Where clauses are performed independantly from the table ml_lead; the
reason is that all
to CHAR_LENGTH(Z).
Eventually only the rows of P3 for which the sum of "gec" is equal to
the number of rows of P3 where the value of "phone_number" is the same
are kept.
Hoping this alternative solution will help a little (validated with
PostgreSQL 8.3.1).
Regards.
P-
