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
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
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
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
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
> 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
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
> 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
>
>
> 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 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
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:
> 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
12 matches
Mail list logo
