I did some editorializing on the FSM README file, in the line of
familiarizing myself with the contents. Attached is an updated version.
Here are a couple of other random comments I jotted in the process:
search_avail makes me nervous: in the presence of a corrupt tree
I think it could index off
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> ... but we still haven't actually
> established that the WAL-logging is causing the performance degradation
> Zdenek observed.
Yeah, that's a good point. I did some simple performance testing on
bulk inserts and updates, and found that while they
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
1) remove WAL logging. I think that FSM record should be recovered
during processing of others WAL records (like insert, update).
Why are we WAL-logging FSM operations at all? It's only a hint.
- to ensure self-consistency of the tr
Tom Lane wrote:
I did a bit of testing and immediately got an Assert failure:
...
The scary part of that is that it gets through the regression tests ---
doesn't leave one with a warm feeling about how much of VACUUM gets
exercised by regression.
Ouch..
I take it the comment at the top of i
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Here's a new patch, updated per your comments.
I did a read-through of the portions of this patch that change the rest
of the system (ie, not the guts of the new FSM itself). Mostly it looks
pretty nice, but I have a few gripes:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
>>> 1) remove WAL logging. I think that FSM record should be recovered
>>> during processing of others WAL records (like insert, update).
Why are we WAL-logging FSM operations at all? It's only a hint.
>> I think we'd still need to WAL log operations t
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> No, FANOUT^4 doesn't fit in int, good catch. Actually, FANOUTPOWERS
> table doesn't need to go that far, so that's just a leftover. It only
> needs to have DEPTH elements. However, we have the same problem if
> DEPTH==3, FANOUT^4 will not fit into
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Here's a new patch, updated per your comments.
I did a read-through of the portions of this patch that change the rest
of the system (ie, not the guts of the new FSM itself). Mostly it looks
pretty nice, but I have a few gripes:
Does smgrimmedsyn
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Suggestions:
1) remove WAL logging. I think that FSM record should be recovered
during processing of others WAL records (like insert, update).
Probably only we need full page write on first modification after
checkpoint.
Hmm, we don't ha
On Sep 17, 2008, at 9:30 AM, Heikki Linnakangas wrote:
I think we'd still need to WAL log operations that decrease the
amount of free space on page. Otherwise, after we have partial
vacuum, we might never revisit a page, and update the FSM, even
though there's usable space on the page, leavi
Zdenek Kotala wrote:
I tested it with DTrace on Solaris 10 and 8CPUs SPARC machine. I got
similar result as you. Main problem in your new implementation is
locking. On small tables where FSM fits on one page clients spend about
3/4 time to waiting on page lock.
That in itself is not that surp
Heikki Linnakangas napsal(a):
Heikki Linnakangas wrote:
Let me describe this test case first:
- The test program calls RecordAndGetPageWithFreeSpace in a tight loop,
with random values. There's no activity to the heap. In normal usage,
the time spent in RecordAndGetWithFreeSpace is minusc
Hi Heikki,
I'm still work on performance test, but I have following
comments/questions/suggestion:
1)
#define NodesPerPage (BLCKSZ - SizeOfPageHeaderData - offsetof(FSMPageData,
fp_nodes))
should be
#define NodesPerPage (BLCKSZ - MAXALIGN(SizeOfPageHeaderData) -
offsetof(FSMPageData, fp_n
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Let me describe this test case first:
- The test program calls RecordAndGetPageWithFreeSpace in a tight loop,
with random values.
What's the distribution of the random values, exactly? In particular,
how do the request sizes comp
Zdenek Kotala wrote:
It looks likes that there are lot of lock issues on FSM pages. When
number of FSM pages is increased then number of collisions is lower. It
is probably why 2 clients significantly speed up between 33MB and 333MB.
Yes, that's what I thought as well. With table size under 3
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Let me describe this test case first:
> - The test program calls RecordAndGetPageWithFreeSpace in a tight loop,
> with random values.
What's the distribution of the random values, exactly? In particular,
how do the request sizes compare to availab
Heikki Linnakangas napsal(a):
Heikki Linnakangas wrote:
I've also been working on a low level benchmark using a C user-defined
function that exercises just the FSM, showing the very raw CPU
performance vs. current implementation. More on that later, but ATM it
looks like the new implementation
Heikki Linnakangas wrote:
I've also been working on a low level benchmark using a C user-defined
function that exercises just the FSM, showing the very raw CPU
performance vs. current implementation. More on that later, but ATM it
looks like the new implementation can be faster or slower than t
Another question:
Does we need random_bool to spread workload? It seems to me a useless, because
it also invokes one backend to use more pages instead of using one which is
already in buffer cache. I think that it should generate a lot of extra i/o. Do
not forget WAL full page write for firsti
Zdenek Kotala wrote:
I have question about FSM structure on the page. If I look into the code
it seems to me that tree structure is "degenerated" on the right side.
It is probably space optimization because complete tree needs BLCKSZ/2
space on the page and rest is empty.
Is my assumption cor
I have question about FSM structure on the page. If I look into the code it
seems to me that tree structure is "degenerated" on the right side. It is
probably space optimization because complete tree needs BLCKSZ/2 space on the
page and rest is empty.
Is my assumption correct? If yes maybe ext
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Do you still have the iGen setup available? Want to give it a shot?
Not sure if I have it configured, need to check. But I'll try it or I'll ask
Jignesh or Paul if they have a free time. They are real benchmark gurus.
Zden
Zdenek Kotala wrote:
Yesterday, I started to reviewing your patch.
Thanks!
1) If I understand correctly the main goal is to improve FSM to cover
all pages in file which is useful for huge database.
That's not a goal per se, though it's true that the new FSM does cover
all pages. The goals
Heikki Linnakangas napsal(a):
Here's an updated FSM patch. Changes since last patch:
Yesterday, I started to reviewing your patch. At the beginning I have
general questions:
1) If I understand correctly the main goal is to improve FSM to cover
all pages in file which is useful for huge dat
Simon Riggs wrote:
On Thu, 2008-09-04 at 11:07 +0300, Heikki Linnakangas wrote:
Scenario: The binary tree on a page is corrupt, so that the value of an
upper node is > Max(leftchild, rightchild).
Consequence: Searchers will notice the corruption while trying to
traverse down that path, and thro
On Thu, 2008-09-04 at 11:07 +0300, Heikki Linnakangas wrote:
> Thanks for the review!
Not as thorough as I would have liked, I must admit.
Thanks for the other confirmations.
> Scenario: The binary tree on a page is corrupt, so that the value of an
> upper node is > Max(leftchild, rightchild).
Thanks for the review!
Simon Riggs wrote:
Can I check some aspects of this related to Hot Standby? Some of them
sound obvious, but worth double checking.
* There will be no need to read FSM by any normal operation of a
read-only transaction, so locking correctness considerations can
possibly be
On Fri, 2008-08-29 at 10:47 +0300, Heikki Linnakangas wrote:
> Here's an updated FSM patch.
Can I check some aspects of this related to Hot Standby? Some of them
sound obvious, but worth double checking.
* There will be no need to read FSM by any normal operation of a
read-only transaction, so
On Fri, 2008-08-29 at 10:47 +0300, Heikki Linnakangas wrote:
> - Per comments and discussion with Simon, I've changed the "bubble up"
> behavior so that when a bottom-level page is updated, if the amount of
> free space was decreased, the change is not immediately bubbled up to
> upper page. I
29 matches
Mail list logo
