On 07/13/2011 11:42 AM, Kevin Grittner wrote:
So transactions without an XID *are* sensitive to
synchronous_commit. That's likely a useful clue.
How much did it help the run time of the SELECT which followed the
UPDATE?
It has surprisingly little impact on the SELECT side:
=> set synchronous
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Huh? If there was never an XID, there's no commit WAL record,
>> hence nothing to make asynchronous.
> If you look at the RecordTransactionCommit() function in xact.c
> you'll see that's not correct.
Oh, hmmm ... that code was written with the ide
Tom Lane wrote:
> Huh? If there was never an XID, there's no commit WAL record,
> hence nothing to make asynchronous.
If you look at the RecordTransactionCommit() function in xact.c
you'll see that's not correct. Currently the commit record has
nothing to do with whether it synchronizes on W
On Wed, Jul 13, 2011 at 1:10 PM, lars wrote:
> On 07/13/2011 08:17 AM, Tom Lane wrote:
>>
>> "Kevin Grittner" writes:
>>>
>>> ... Jeff does raise a good point, though -- it seems odd
>>> that WAL-logging of this pruning would need to be synchronous.
>>
>> Yeah, we need to get to the bottom of th
lars wrote:
> On 07/13/2011 07:46 AM, Kevin Grittner wrote:
>>
>> I've mentioned this in a hand-wavy general sense, but I should
>> have mentioned specifics ages ago: for a database where the
>> active portion of the database is fully cached, it is best to set
>> seq_page_cost and random_page_cost
On 07/13/2011 07:46 AM, Kevin Grittner wrote:
I've mentioned this in a hand-wavy general sense, but I should have
mentioned specifics ages ago: for a database where the active
portion of the database is fully cached, it is best to set
seq_page_cost and random_page_cost to the same value, somewhe
On 07/13/2011 08:17 AM, Tom Lane wrote:
"Kevin Grittner" writes:
... Jeff does raise a good point, though -- it seems odd
that WAL-logging of this pruning would need to be synchronous.
Yeah, we need to get to the bottom of that. If there's enough
shared_buffer space then it shouldn't be.
Thi
"Kevin Grittner" writes:
> ... Jeff does raise a good point, though -- it seems odd
> that WAL-logging of this pruning would need to be synchronous.
Yeah, we need to get to the bottom of that. If there's enough
shared_buffer space then it shouldn't be.
> We
> support asynchronous commits -- wh
On Tue, Jul 12, 2011 at 6:15 PM, lars wrote:
> Back to the first case, here's an strace from the backend doing the select
> right after the updates.
> write(13,
> "f\320\1\0\1\0\0\0\273\0\0\0\0\340\27\22`\32\0\0002833!000"..., 2400256)
> = 2400256
On Wed, Jul 13, 2011 at 9:46 AM, Kevin Grittn
[combining responses to two posts on this thread by lars]
lars wrote:
> On the face of it, though, this looks like Postgres would not be
> that useful as database that resides (mostly) in the cache.
I've mentioned this in a hand-wavy general sense, but I should have
mentioned specifics ages
10 matches
Mail list logo
