[combining responses to two posts on this thread by lars]
lars lhofha...@yahoo.com 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
On Tue, Jul 12, 2011 at 6:15 PM, lars lhofha...@yahoo.com 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 Grittner kevin.gritt...@wicourts.gov 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
On 07/13/2011 08:17 AM, Tom Lane wrote:
Kevin Grittnerkevin.gritt...@wicourts.gov 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
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,
lars lhofha...@yahoo.com 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
On Wed, Jul 13, 2011 at 1:10 PM, lars lhofha...@yahoo.com wrote:
On 07/13/2011 08:17 AM, Tom Lane wrote:
Kevin Grittnerkevin.gritt...@wicourts.gov 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
Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
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
10 matches
Mail list logo
