On Tue, 2012-05-01 at 10:08 -0400, Robert Haas wrote:
We've previously discussed the possible desirability of extending
relations in larger increments, rather than one block at a time, for
performance reasons. I attempted to determine how much performance we
could possibly buy this way, and
Robert,
* Stephen Frost (sfr...@snowman.net) wrote:
In all seriousness, this is not a great test case unless you can
provide some scripts to make it easy to run it in a reproducible
fashion. Can you?
Yeah, sure, I'll do that. The PostGIS folks have scripts, but they're
kind of ugly,
On 2012-05-01 22:06, Robert Haas wrote:
It might also be interesting to provide a mechanism to pre-extend a
relation to a certain number of blocks, though if we did that we'd
have to make sure that autovac got the memo not to truncate those
pages away again.
Good point. And just to check
On Wed, May 2, 2012 at 7:16 AM, Jeroen Vermeulen j...@xs4all.nl wrote:
On 2012-05-01 22:06, Robert Haas wrote:
It might also be interesting to provide a mechanism to pre-extend a
relation to a certain number of blocks, though if we did that we'd
have to make sure that autovac got the memo not
Excerpts from Robert Haas's message of mié may 02 08:14:36 -0400 2012:
On Wed, May 2, 2012 at 7:16 AM, Jeroen Vermeulen j...@xs4all.nl wrote:
On 2012-05-01 22:06, Robert Haas wrote:
It might also be interesting to provide a mechanism to pre-extend a
relation to a certain number of blocks,
On Wed, May 2, 2012 at 12:26 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié may 02 08:14:36 -0400 2012:
On Wed, May 2, 2012 at 7:16 AM, Jeroen Vermeulen j...@xs4all.nl wrote:
On 2012-05-01 22:06, Robert Haas wrote:
It might also be interesting
Robert Haas robertmh...@gmail.com writes:
On Wed, May 2, 2012 at 12:26 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Hm. I see those two things as different -- to me, bloat is unremoved
dead tuples, whereas slack space would be free space that can be reused
by new tuples. Slack space
Excerpts from Robert Haas's message of mié may 02 12:37:35 -0400 2012:
On Wed, May 2, 2012 at 12:26 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié may 02 08:14:36 -0400 2012:
On Wed, May 2, 2012 at 7:16 AM, Jeroen Vermeulen j...@xs4all.nl
On Wed, May 2, 2012 at 12:46 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Agreed. Perhaps to solve this issue what we need is a way to migrate
tuples from later pages into earlier ones. (This was one of the points,
never resolved, that we discussed during the VACUUM FULL rework.)
Excerpts from Robert Haas's message of mié may 02 12:55:17 -0400 2012:
On Wed, May 2, 2012 at 12:46 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Agreed. Perhaps to solve this issue what we need is a way to migrate
tuples from later pages into earlier ones. (This was one of the
On Tue, May 1, 2012 at 3:08 PM, Robert Haas robertmh...@gmail.com wrote:
We've previously discussed the possible desirability of extending
relations in larger increments, rather than one block at a time, for
performance reasons. I attempted to determine how much performance we
could possibly
On Tuesday, May 01, 2012 04:08:27 PM Robert Haas wrote:
We've previously discussed the possible desirability of extending
relations in larger increments, rather than one block at a time, for
performance reasons. I attempted to determine how much performance we
could possibly buy this way, and
On Tue, May 1, 2012 at 10:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
Fair enough, but my understanding was that tests showed that the
extension lock was a bottleneck, so doing extensions in larger chunks
should reduce the time we spend waiting for a lock and thus improve
performance. So
On Tue, May 1, 2012 at 10:31 AM, Andres Freund and...@anarazel.de wrote:
efficient than our current method - I'm guessing that it actually
writes the updated metadata back to disk, where write() does not (this
makes one wonder how safe it is to count on write to have the behavior
we need here
On Tuesday, May 01, 2012 05:06:11 PM Robert Haas wrote:
On Tue, May 1, 2012 at 10:31 AM, Andres Freund and...@anarazel.de wrote:
efficient than our current method - I'm guessing that it actually
writes the updated metadata back to disk, where write() does not (this
makes one wonder how safe
On Tue, May 1, 2012 at 11:42 AM, Andres Freund and...@anarazel.de wrote:
There is the question whether this should be done in the background
though, so the relation extension lock is never hit in anything
time-critical...
Yeah, although I'm fuzzy on how and whether that can be made to work,
On Tue, May 1, 2012 at 10:22 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, May 1, 2012 at 3:08 PM, Robert Haas robertmh...@gmail.com wrote:
We've previously discussed the possible desirability of extending
relations in larger increments, rather than one block at a time, for
performance
Christopher Browne cbbro...@gmail.com writes:
Try to make sure that one of the scenarios involves there being
multiple writers.
One of the relevant cases is where there are multiple writers, where
they may wind up fighting over the last page in the table. If free
space is in that one page,
Excerpts from Tom Lane's message of mar may 01 13:19:48 -0400 2012:
Christopher Browne cbbro...@gmail.com writes:
Try to make sure that one of the scenarios involves there being
multiple writers.
One of the relevant cases is where there are multiple writers, where
they may wind up
On Tue, May 1, 2012 at 3:01 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
The system is supposed to be designed to avoid that; we try to hand out
pages with free space to different backends. One of the advantages of
the current page-at-a-time setup is that when there is *no* free space
* Robert Haas (robertmh...@gmail.com) wrote:
I think the first thing we need here is a good test case, so we're
clear on what we're trying to solve. I was just hoping to make file
extension *faster* and what you and Simon are talking about is making
it scale better in the face of heavy
On Tue, May 1, 2012 at 3:48 PM, Stephen Frost sfr...@snowman.net wrote:
Try loading the TIGER 2011 data into a single table, where you load each
county (or perhaps state) in a separate, parallel, process. That's what
I was doing when I hit this lock full-force and bitched about it on this
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, May 1, 2012 at 3:48 PM, Stephen Frost sfr...@snowman.net wrote:
I'd be happy to help construct that case, as well as test any changes in
this area which might help address it (on a 10G SSD-backed SAN..).
Hmm, can you ship me one
23 matches
Mail list logo
