From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | rod(at)iol(dot)ie |
Cc: | PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: SQL - finding next date |
Date: | 2007-04-12 17:38:49 |
Message-ID: | b42b73150704121038i686314dcj74d824d40ae2af13@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 4/12/07, Raymond O'Donnell <rod(at)iol(dot)ie> wrote:
> On 12/04/2007 18:01, Merlin Moncure wrote:
>
> > I tested it and this is much faster than 'where exists' solution.
>
> Is this an attribute of PostgreSQL in particular, or would it be true of
> RDBMSs in general?
evaluation of subqueries is one place where various databases quite a
lot...postgresql one of the nice things about postgresql is that sql
optimization usually (but not always) entails finding the most direct
query to attack the problem. other databases might prefer joins or
standard subquery approach (where in/exists, etc).
my suggestion to return the record in a field as a composite type is a
non-standard trick (i think...do composite types exist in the sql
standard?).
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-04-12 18:17:19 | Re: SQL - finding next date |
Previous Message | Tom Lane | 2007-04-12 17:24:51 | Re: Autovac _scale_ settings not changed by SIGHUP? |