8.4 from CVS HEAD:
EXPLAIN ANALYZE select * from (select n, 1 as r from generate_series(1, 10)
as n union all select n, 2 from generate_series(1, 10) as n) as x where r =
3;
QUERY PLAN
Scott Marlowe writes:
> On Wed, Jul 1, 2009 at 11:52 AM, Tom Lane wrote:
>> Scott Marlowe writes:
>>> Sometimes putting a where clause portion into the on clause helps.
>>> like:
>>> select * from a left join b on (a.id=b.id) where a.somefield=2
>>> might run faster with
>>> select * from a left
On Wed, Jul 1, 2009 at 11:52 AM, Tom Lane wrote:
> Scott Marlowe writes:
>> Sometimes putting a where clause portion into the on clause helps.
>> like:
>> select * from a left join b on (a.id=b.id) where a.somefield=2
>> might run faster with
>> select * from a left join b on (a.id=bid. and a.some
Rui Carvalho wrote:
hum thanks a lot for the quick answer,
if is not abuse of your patience
what is the best alternative to the LEFT OUTER JOINS?
I meant I wasn't sure whether you really meant *outer* joins. Too many
of them looked kinda suspicious :-)
If you *do* need them, then there is no
Scott Marlowe writes:
> Sometimes putting a where clause portion into the on clause helps.
> like:
> select * from a left join b on (a.id=b.id) where a.somefield=2
> might run faster with
> select * from a left join b on (a.id=bid. and a.somefield=2);
> but it's hard to say.
Uh, those are not the
On Wed, Jul 1, 2009 at 11:37 AM, Rui Carvalho wrote:
> hum thanks a lot for the quick answer,
>
> if is not abuse of your patience
>
> what is the best alternative to the LEFT OUTER JOINS?
Hard to say. Generally, when you really do need a left, right, or
full outer join, you need it, and there's
hum thanks a lot for the quick answer,
if is not abuse of your patience
what is the best alternative to the LEFT OUTER JOINS?
RC
On Wed, Jul 1, 2009 at 6:12 PM, Mike Ivanov wrote:
> > Merge Join (cost=111885.70..319492.88 rows=13016048 width=620)
>
> The outermost merge join has to go throu
> Merge Join (cost=111885.70..319492.88 rows=13016048 width=620)
The outermost merge join has to go through 13 million rows. If you
remove "distinct on (bien.uid)", you'll see that.
> LEFT outer JOIN ville ON ville.uid = bien.ref_ville
> LEFT outer JOIN freguesia_ville ON freguesia_ville.ref_
Rui Carvalho wrote:
SELECT distinct on (bien.uid) bien.uid , bien.date_creation ,
bien.date_modification , bien.nom , bien.numero_voie , bien.mer ,
bien.proximite , bien.nom_voie , bien.type_voie , bien.lieudit ,
bien.arrondissement , bien.montagne , bien.complement_adresse ,
bien.xy_geo ,
Hi Rui,
i have this query (i think is a simple one)
Could you EXPLAIN ANALYZE the query and show the results please?
Thanks,
Mike
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-perf
HI Gurus ,
i have this query (i think is a simple one)
it takes me 1,7s to run it, it's not to long, but considering it takes 1,7s
to return 71lines makes me wonder... is there anyother way to do this, on a
first look??
any sugestion would be largely appreciated.
SELECT distinct on (bien.uid) bi
11 matches
Mail list logo
