From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Shawn Debnath <sdn(at)amazon(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Refactoring the checkpointer's fsync request queue |
Date: | 2019-03-05 16:33:54 |
Message-ID: | CA+hUKGJX302ctT26zXc1w7PvrwcUWHNUH0casYhA6Si0d7xDng@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 6, 2019 at 5:07 AM Shawn Debnath <sdn(at)amazon(dot)com> wrote:
> Confirmed. Patch shows 8900 ms vs 192 ms on master for the insert test.
> Interesting! It's reproducible so should be able to figure out what's
> going on. The only thing we do in ForwardSyncRequest() is split up the 8
> bits into 2x4 bits and copy the FileTagData structure to the
> checkpointer queue. Will report back what I find.
More review, all superficial stuff:
+typedef struct
+{
+ RelFileNode rnode;
+ ForkNumber forknum;
+ SegmentNumber segno;
+} FileTagData;
+
+typedef FileTagData *FileTag;
Even though I know I said we should take FileTag by pointer, and even
though there is an older tradition in the tree of having a struct
named "FooData" and a corresponding pointer typedef named "Foo", as
far as I know most people are not following the convention for new
code and I for one don't like it. One problem is that there isn't a
way to make a pointer-to-const type given a pointer-to-non-const type,
so you finish up throwing away const from your programs. I like const
as documentation and a tiny bit of extra compiler checking. What do
you think about "FileTag" for the struct and eg "const FileTag *tag"
when receiving one as a function argument?
-/* internals: move me elsewhere -- ay 7/94 */
Aha, about time too!
+#include "fmgr.h"
+#include "storage/block.h"
+#include "storage/relfilenode.h"
+#include "storage/smgr.h"
+#include "storage/sync.h"
Why do we need to include fmgr.h in md.h?
+/* md storage manager funcationality */
Typo.
+/* md sync callback forward declarations */
These aren't "forward" declarations, they're plain old declarations.
+extern char* mdfilepath(FileTag ftag);
Doesn't really matter too much because all of this will get
pgindent-ed at some point, but FYI we write "char *md", not "char*
md".
#include "storage/smgr.h"
+#include "storage/md.h"
#include "utils/hsearch.h"
Bad sorting.
+ FileTagData tag;
+ tag.rnode = reln->smgr_rnode.node;
+ tag.forknum = forknum;
+ tag.segno = seg->mdfd_segno;
I wonder if it would be better practice to zero-initialise that
sucker, so that if more members are added we don't leave them
uninitialised. I like the syntax "FileTagData tag = {{0}}".
(Unfortunately extra nesting required here because first member is a
struct, and C99 doesn't allow us to use empty {} like C++, even though
some versions of GCC accept it. Rats.)
--
Thomas Munro
https://enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-03-05 16:39:27 | Re: jsonpath |
Previous Message | Thomas Munro | 2019-03-05 16:23:23 | Re: Rare SSL failures on eelpout |