To: pgsql-sql@postgresql.org
From: Thomas Kellerer <spam_eater@gmx.net>
Subject: Re: Most recent row
Date: Mon, 8 May 2017 14:19:14 +0200
Lines: 29
Message-ID: <oepnns$bod$1@blaine.gmane.org>
References: <201705050925.04194.gary.stainburn@ringways.co.uk>
 <CAKFQuwb5ap3=_VvWOAnYG6E4aChk3jQTztube+UW=Kk29V01fQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23)
 Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
In-Reply-To: 
 <CAKFQuwb5ap3=_VvWOAnYG6E4aChk3jQTztube+UW=Kk29V01fQ@mail.gmail.com>
Content-Language: en-GB
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

David G. Johnston schrieb am 05.05.2017 um 17:14:
> ​I would start with something using DISTINCT ON and avoid redundant
> data. If performance starts to suck I would then probably add a field
> to people where you can record the most recent assessment id and
> which you would change via a trigger on assessments.
> 
> (not tested)​
> 
> ​SELECT DISTINCT ON (p) p, a
> FROM people p
> LEFT JOIN ​assessments a USING (p_id)
> ORDER BY p, a.as_timestamp DESC;
> 
> David J.
> 

I would probably put the evaluation of the "most recent assessment" into a derived table:

  select *
  from people p
  join (
    select distinct on (p_id) *
    from assessments
    order by p_id, as_timestamp desc
  ) a on a.p_id = p.id;

In my experience joining with the result of the distinct on () is quicker then applying the distinct on () on the result of the join.


-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql