johno writes:
> On Tue, Jul 22, 2014 at 4:53 AM, Tom Lane wrote:
>> johno writes:
>>> The obvious query is
>>> SELECT * FROM register_uz_accounting_entities
>>> WHERE effective_on > '2014-07-11' OR (effective_on = '2014-07-11' AND
>>> id > 1459)
>>> ORDER BY effective_on, id
>>> LIMIT 100
>> A
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 timestamp I need to a
> > se
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 timestamp I need to a
> second condition, that states that I want to return rows having
>
>
> 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
johno wrote
> Oh, yes I do understand that if I remove the outer limit, the semantics of
> the query would change. However I am looking for the counterexample *with*
> the limit clauses. Maybe I just don't understand what relationally
> equivalent means, sorry about that.
>
> BTW this is to my und
Oh, yes I do understand that if I remove the outer limit, the semantics of
the query would change. However I am looking for the counterexample *with*
the limit clauses. Maybe I just don't understand what relationally
equivalent means, sorry about that.
BTW this is to my understanding a very simila
johno wrote
> Thanks for the quick reply David!
>
> However I am still unsure how these two queries are not relationally
> equivalent. I am struggling to find a counterexample where the first and
> third query (in email, not in gist) would yield different results. Any
> ideas?
Remove the outer LI
Thanks for the quick reply David!
However I am still unsure how these two queries are not relationally
equivalent. I am struggling to find a counterexample where the first and
third query (in email, not in gist) would yield different results. Any
ideas?
Jano
On Mon, Jul 21, 2014 at 11:31 PM, Da
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
and the optimizer cannot change the behavior of the query which it is
optimizing. i.e. you
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
Mark Kirkwood wrote:
> On 12/07/14 01:19, Kevin Grittner wrote:
>>
>> It might be worth a test using a cpuset to interleave OS cache and
>> the NUMA patch I submitted to the current CF to see whether this is
>> getting into territory where the patch makes a bigger difference.
>> I would expect it
Please keep the list on CC: in your responses.
Benjamin Dugast wrote:
> 2014-07-18 13:11 GMT+02:00 Albe Laurenz :
>> This sounds a lot like checkpoint I/O spikes.
>>
>> Check with the database server log if the freezes coincide with checkpoints.
>>
>> You can increase checkpoint_segments when you
12 matches
Mail list logo
