>
> No, it doesn't. Read it again ... or read up on row comparisons,
> if you're unfamiliar with that notation. The above queries are
> exactly equivalent per spec.
>
Wow, this is great. Thanks.
On Tue, Jul 22, 2014 at 4:53 AM, Tom Lane wrote:
> johno writes:
> > I am trying to optimize a simple query that returns first 100 rows that
> > have been updated since a given timestamp (ordered by timestamp and id
> > desc). If there are several rows with the same
>
>
> Try following my lead and bottom-post, please.
>
Sorry for that.
>
> Anyway, the query has no clue that because of the final LIMIT 100 that the
> two different feeding queries are just going to happen to end up providing
> the same result. Maybe, in this particular instance, it is theoret
very similar scenario to how partitioned
tables work and push down limit and where conditions. Why is this not
possible in this case?
Jano
On Mon, Jul 21, 2014 at 11:54 PM, David G Johnston <
david.g.johns...@gmail.com> wrote:
> johno wrote
> > Thanks for the quick reply David!
> &
, David G Johnston <
david.g.johns...@gmail.com> wrote:
> johno wrote
> > The question is... why is the query planner unable to make this
> > optimization for the slow query? What am I missing?
>
> Short answer - your first and last queries are not relationally equivalent
Hi there,
I am trying to optimize a simple query that returns first 100 rows that
have been updated since a given timestamp (ordered by timestamp and id
desc). If there are several rows with the same timestamp I need to a
second condition, that states that I want to return rows having the given
t
