Re: [HACKERS] [pgsql-performance] [GENERAL] Large databases, performance

On Tue, Oct 08, 2002 at 11:14:11AM +0530, Shridhar Daithankar wrote: > On 7 Oct 2002 at 11:21, Tom Lane wrote: > > > "Shridhar Daithankar" <[EMAIL PROTECTED]> writes: > > > I say if it's a char field, there should be no indicator of length as > > > it's not required. Just store those many charact

Re: [HACKERS] Analysis of ganged WAL writes

Curtis Faith kirjutas T, 08.10.2002 kell 01:04: > > I may be missing something obvious, but I don't see a way to get more > > than 1 trx/process/revolution, as each previous transaction in that > > process must be written to disk before the next can start, and the only > > way it can be written to

Re: [GENERAL] [HACKERS] Hot Backup

On 7 Oct 2002 at 13:48, Neil Conway wrote: > "Sandeep Chadha" <[EMAIL PROTECTED]> writes: > > Postgresql has been lacking this all along. I've installed postgres > > 7.3b2 and still don't see any archive's flushed to any other > > place. Please let me know how is hot backup procedure implemented

Re: [HACKERS] [pgsql-performance] [GENERAL] Large databases, performance

On 7 Oct 2002 at 11:21, Tom Lane wrote: > "Shridhar Daithankar" <[EMAIL PROTECTED]> writes: > > I say if it's a char field, there should be no indicator of length as > > it's not required. Just store those many characters straight ahead.. > > Your assumption fails when considering UNICODE or oth

Re: [HACKERS] Dirty Buffer Writing [was Proposed LogWriter Scheme]

Curtis Faith wrote: > > This is the trickle syncer. It prevents bursts of disk activity every > > 30 seconds. It is for non-fsync writes, of course, and I assume if the > > kernel buffers get low, it starts to flush faster. > > AFAICT, the syncer only speeds up when virtual memory paging fills

Re: [HACKERS] Dirty Buffer Writing [was Proposed LogWriter Scheme]

> Greg Copeland <[EMAIL PROTECTED]> writes: > > Doesn't this also increase the likelihood that people will be > > running in a buffer-poor environment more frequently that I > > previously asserted, especially in very heavily I/O bound > > systems? Unless I'm mistaken, that opens the door for a >

Re: [HACKERS] Proposed LogWriter Scheme, WAS: Potential Large

I sent this yesterday, but it seems not to have made it to the list... I have a couple of comments orthogonal to the present discussion. 1) It would be fairly easy to write log records over a network to a dedicated process on another system. If the other system has an uninterruptible powe

Re: [HACKERS] Where to call SetQuerySnapshot

Tom Lane wrote: > 1. Where is the cleanest place to call SetQuerySnapshot() for utility > statements that need it? Should we follow the lead of the existing > COPY code, and add the call to the ExecuteStmt case in utility.c? > Or should we move the calls into the command-specific routines (DoCopy

Re: [HACKERS] Dirty Buffer Writing [was Proposed LogWriter Scheme]

Greg Copeland <[EMAIL PROTECTED]> writes: > Doesn't this also increase the likelihood that people will be running in > a buffer-poor environment more frequently that I previously asserted, > especially in very heavily I/O bound systems? Unless I'm mistaken, that > opens the door for a general cas

[HACKERS] Where to call SetQuerySnapshot

I noticed that the new EXECUTE statement does not call SetQuerySnapshot, which seems like a bad thing. The omission is masked by the defensive code in CopyQuerySnaphot, which will automatically do SetQuerySnapshot if it hasn't been done yet in the current transaction. However, this doesn't provi

Re: [HACKERS] Analysis of ganged WAL writes

> I may be missing something obvious, but I don't see a way to get more > than 1 trx/process/revolution, as each previous transaction in that > process must be written to disk before the next can start, and the only > way it can be written to the disk is when the disk heads are on the > right plac

Re: [HACKERS] 7.2.3 patching done

On Mon, Oct 07, 2002 at 09:22:38PM +0200, Peter Eisentraut wrote: > Tom Lane writes: > > > But the source distribution hasn't *got* any binary files. > > There are some under doc/src/graphics, and then there are > doc/postgres.tar.gz and doc/man.tar.gz. And what about publishing xdelta patches?

Re: [HACKERS] Analysis of ganged WAL writes

Well, I was thinking that aio may not be available on all platforms, thus the conditional compile option. On the other hand, wouldn't you pretty much want it either on or off for all instances? I can see that it would be nice for testing though. ;) Greg On Mon, 2002-10-07 at 16:23, Justin Cl

Re: [HACKERS] Proposed LogWriter Scheme, WAS: Potential Large

On Mon, 2002-10-07 at 21:35, Neil Conway wrote: > Greg Copeland <[EMAIL PROTECTED]> writes: > > Ya, I have read this before. The problem here is that I'm not aware of > > which AIO implementation on Linux is the forerunner nor do I have any > > idea how it's implementation or performance details

Re: [HACKERS] Analysis of ganged WAL writes

"Curtis Faith" <[EMAIL PROTECTED]> writes: >> Well, too bad. If you haven't gotten your commit record down to disk, >> then *you have not committed*. This is not negotiable. (If you think >> it is, then turn off fsync and quit worrying ;-)) > I've never disputed this, so if I seem to be sugges

Re: [HACKERS] Dirty Buffer Writing [was Proposed LogWriter Scheme]

On Mon, 2002-10-07 at 15:28, Bruce Momjian wrote: > This is the trickle syncer. It prevents bursts of disk activity every > 30 seconds. It is for non-fsync writes, of course, and I assume if the > kernel buffers get low, it starts to flush faster. Doesn't this also increase the likelihood that

Re: [HACKERS] Analysis of ganged WAL writes

Greg Copeland wrote: > If so, I assume it would become a configure option (--with-aio)? Or maybe a GUC "use_aio" ? :-) Regards and best wishes, Justin Clift > > Regards, > > Greg > > >

Re: [HACKERS] Analysis of ganged WAL writes

On Mon, 2002-10-07 at 16:06, Curtis Faith wrote: > > Well, too bad. If you haven't gotten your commit record down to disk, > > then *you have not committed*. This is not negotiable. (If you think > > it is, then turn off fsync and quit worrying ;-)) > At this point, I think we've come full ci

Re: [HACKERS] Analysis of ganged WAL writes

> Well, too bad. If you haven't gotten your commit record down to disk, > then *you have not committed*. This is not negotiable. (If you think > it is, then turn off fsync and quit worrying ;-)) I've never disputed this, so if I seem to be suggesting that, I've beee unclear. I'm just assuming

Re: [HACKERS] Analysis of ganged WAL writes

On Tue, 2002-10-08 at 01:27, Tom Lane wrote: > > The scheme we now have (with my recent patch) essentially says that the > commit delay seen by any one transaction is at most two disk rotations. > Unfortunately it's also at least one rotation :-(, except in the case > where there is no contention,

Re: [HACKERS] Dirty Buffer Writing [was Proposed LogWriter Scheme]

> This is the trickle syncer. It prevents bursts of disk activity every > 30 seconds. It is for non-fsync writes, of course, and I assume if the > kernel buffers get low, it starts to flush faster. AFAICT, the syncer only speeds up when virtual memory paging fills the buffers past a threshold a

Re: [HACKERS] Analysis of ganged WAL writes

On Tue, 2002-10-08 at 00:12, Curtis Faith wrote: > Tom, first of all, excellent job improving the current algorithm. I'm glad > you look at the WALCommitLock code. > > > This must be so because the backends that are > > released at the end of any given disk revolution will not be able to > > part

Re: [HACKERS] Dirty Buffer Writing [was Proposed LogWriter Scheme]

Curtis Faith wrote: > Good points. > > Now for some surprising news (at least it surprised me). > > I researched the file system source on my system (FreeBSD 4.6) and found > that the behavior was optimized for non-database access to eliminate > unnecessary writes when temp files are created and

Re: [HACKERS] Analysis of ganged WAL writes

"Curtis Faith" <[EMAIL PROTECTED]> writes: > Even the theoretical limit you mention of one transaction per revolution > per committing process seem like a significant bottleneck. Well, too bad. If you haven't gotten your commit record down to disk, then *you have not committed*. This is not neg

Re: [HACKERS] Hot Backup

Hmmm, Then are there any new enhancements as far as backups are concerned between current 7.2.x to 7.3.x. Like can we do a tar when database is up and running or another feature. Thanks a bunch in advance. -Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED]] Sent: Monday, Oct

Re: [HACKERS] v7.2.3 - tag'd, packaged ... need it checked ...

Marc G. Fournier writes: > Looks good from my end, Peter, I pulled the same docs that I pulled for > v7.2.2, which I hope is okay? Probably not, because the version number needs to be changed and they need to be rebuilt for each release. -- Peter Eisentraut [EMAIL PROTECTED] --

Re: [HACKERS] 7.2.3 patching done

Tom Lane writes: > But the source distribution hasn't *got* any binary files. There are some under doc/src/graphics, and then there are doc/postgres.tar.gz and doc/man.tar.gz. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP

Re: [HACKERS] Analysis of ganged WAL writes

Tom, first of all, excellent job improving the current algorithm. I'm glad you look at the WALCommitLock code. > This must be so because the backends that are > released at the end of any given disk revolution will not be able to > participate in the next group commit, if there is already at leas

[HACKERS] Dirty Buffer Writing [was Proposed LogWriter Scheme]

> On Sun, 2002-10-06 at 11:46, Tom Lane wrote: > > I can't personally get excited about something that only helps if your > > server is starved for RAM --- who runs servers that aren't fat on RAM > > anymore? But give it a shot if you like. Perhaps your analysis is > > pessimistic. > > I don't

Re: [HACKERS] BTree metapage lock and freelist structure

Alvaro Herrera <[EMAIL PROTECTED]> writes: > There doesn't seem to be a way to acquire two different locks on the > same page, so I propose to lock the InvalidBlockNumer for the btree, and > use that as the lock to be obtained before doing extend, addfree, > getfree or shrink. The setroot/getroot

Re: Parallel Executors [was RE: [HACKERS] Threaded Sorting]

> Curtis Faith wrote: > > > The current transaction/user state seems to be stored in process > > global space. This could be changed to be a sointer to a struct > > stored in a back-end specific shared memory area which would be > > accessed by the executor process at execution start. The backend

Re: [HACKERS] Hot Backup

"Sandeep Chadha" <[EMAIL PROTECTED]> writes: > Postgresql has been lacking this all along. I've installed postgres > 7.3b2 and still don't see any archive's flushed to any other > place. Please let me know how is hot backup procedure implemented in > current 7.3 beta(2) release. AFAIK no such hot

Re: [HACKERS] Analysis of ganged WAL writes

I wrote: > That says that the best possible throughput on this test scenario is 5 > transactions per disk rotation --- the CPU is just not capable of doing > more. I am actually getting about 4 xact/rotation for 10 or more > clients (in fact it seems to reach that plateau at 8 clients, and be > c

Re: Parallel Executors [was RE: [HACKERS] Threaded Sorting]

Curtis Faith wrote: > The current transaction/user state seems to be stored in process > global space. This could be changed to be a sointer to a struct > stored in a back-end specific shared memory area which would be > accessed by the executor process at execution start. The backend > would des

[HACKERS] Hot Backup

Hello to all the Doers of Postgres!!! Last time I went through forums, people spoke highly about 7.3 and its capability to do hot backups. My problem is if the database goes down and I lose my main data store, then I will lose all transactions back to the time I did the pg_dump. Other database

[HACKERS] BTree metapage lock and freelist structure

Hello hackers, I'm thinking about the btree metapage locking problem. In the current situation there are three operations that lock the metapage: 1. when looking for the root page (share lock, "getroot") 2. when setting a new root page (exclusive lock, "setroot") 3. when extending the relation (

Re: [HACKERS] Table spaces again [was Re: Threaded Sorting]

Shridhar Daithankar <[EMAIL PROTECTED]> wrote: [snip] > On 7 Oct 2002 at 15:52, Hans-Jürgen Schönig wrote: [snip] > > With tablespaces you can assign 30mb to use a, 120mb to user b etc. ... > > Table spaces are a nice abstraction layer to the file system. > > Hmm.. And how does that fit in databas

Re: [HACKERS] Proposed LogWriter Scheme, WAS: Potential Large

Greg Copeland <[EMAIL PROTECTED]> writes: > Ya, I have read this before. The problem here is that I'm not aware of > which AIO implementation on Linux is the forerunner nor do I have any > idea how it's implementation or performance details defer from that of > other implementations on other plat

[HACKERS] reminder for those working on docs

Since 7.4 is getting real close and docs are going to be going through their final once-overs. Please remember to have a look at the DocNote comments that have been submitted. Once 7.4 is released the current notes will be gone. http://www.postgresql.org/idocs/checknotes.php The above

Re: [HACKERS] Proposed LogWriter Scheme, WAS: Potential Large

On Mon, 2002-10-07 at 10:38, Antti Haapala wrote: > Browsed web and came across this piece of text regarding a Linux-KAIO > patch by Silicon Graphics... > Ya, I have read this before. The problem here is that I'm not aware of which AIO implementation on Linux is the forerunner nor do I have any

Re: [HACKERS] Moving to PostGres

"Benjamin Stewart" <[EMAIL PROTECTED]> writes: > 1. What is the postgresql equiv to Stored procedures and can they be written > in another langauage such s JAVA? PostgreSQL supports user-defined functions; in 7.3 (currently in beta) they can return sets of tuples. You can define functions in Jav

Re: [HACKERS] [GENERAL] Large databases, performance

> if i'm not mistaken, a char(n)/varchar(n) column is stored as a 32-bit > integer specifying the length followed by as many characters as the > length tells. On 32-bit Intel hardware this structure is aligned on a > 4-byte boundary. Yes. > | opc0 char (3) nono 8 4 > | opc1

Re: [HACKERS] Proposed LogWriter Scheme, WAS: Potential Large

On 6 Oct 2002, Greg Copeland wrote: > On Sat, 2002-10-05 at 14:46, Curtis Faith wrote: > > > > 2) aio_write vs. normal write. > > > > Since as you and others have pointed out aio_write and write are both > > asynchronous, the issue becomes one of whether or not the copies to the > > file system

Re: Table spaces again [was Re: [HACKERS] Threaded Sorting]

Is this NOT what I have been after for many months now. I dropped the tablespace/location idea before 7.2 because that didn't seem to be any interest. Please see my past email's for the SQL commands and on disk directory layout I have proposed. I have a working 7.2 system with tablespaces/loc

Re: Table spaces again [was Re: [HACKERS] Threaded Sorting]

> > Quotas are handled differently on ever platform (if available). >>>Yeah. But that's sysadmins responsibility not DBA's. >>> >>> >>Maybe many people ARE the sysadmins of their PostgreSQL box ... >>When developing a database with an open mind people should try to see

Re: [HACKERS] [pgsql-performance] [GENERAL] Large databases, performance

"Shridhar Daithankar" <[EMAIL PROTECTED]> writes: > I say if it's a char field, there should be no indicator of length as > it's not required. Just store those many characters straight ahead.. Your assumption fails when considering UNICODE or other multibyte character encodings.

Re: [HACKERS] [GENERAL] Large databases, performance

On Mon, 07 Oct 2002 19:48:31 +0530, "Shridhar Daithankar" <[EMAIL PROTECTED]> wrote: >I say if it's a char field, there should be no indicator of length as it's not >required. Just store those many characters straight ahead.. This is out of reach for a quick hack ... >Sure. But the server machi

Re: Table spaces again [was Re: [HACKERS] Threaded Sorting]

=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes: > how would you handle table spaces? The plan that's been discussed simply defines a tablespace as being a directory somewhere; physical storage of individual tables would remain basically the same, one or more files under the c

Re: Table spaces again [was Re: [HACKERS] Threaded Sorting]

On 7 Oct 2002 at 16:49, Hans-Jürgen Schönig wrote: > >Mount a directory on a partition. If the data exceeds on that partition, there > >would be disk error. Like tablespace getting overflown. I have seen both the > >scenarios in action.. > Of course it can be done somehow. However, with tablesp

Re: Table spaces again [was Re: [HACKERS] Threaded Sorting]

>>>2) What a directory structure does not offer that table space does? >>> >>> >>You need to the command line in order to manage quotas - you might not >>want that. >> >> > >Mount a directory on a partition. If the data exceeds on that partition, there >would be disk error. Like table

Re: [HACKERS] [pgsql-performance] [GENERAL] Large databases, performance

On 7 Oct 2002 at 10:30, Tom Lane wrote: > "Shridhar Daithankar" <[EMAIL PROTECTED]> writes: > > MySQL 3.23.52 with innodb transaction support: > > > 4 concurrent queries:- 257.36 ms > > 40 concurrent queries :- 35.12 ms > > > Postgresql 7.2.2 > > > 4 concurrent queries

Re: Table spaces again [was Re: [HACKERS] Threaded Sorting]

On 7 Oct 2002 at 15:52, Hans-Jürgen Schönig wrote: > >Can anybody please tell me in detail.(Not just a pointing towards TODO items) > >1) What a table space supposed to offer? > They allow you to define a maximum amount of storage for a certain set > of data. Use quota > They help you to defin

Re: [HACKERS] [pgsql-performance] [GENERAL] Large databases, performance

"Shridhar Daithankar" <[EMAIL PROTECTED]> writes: > MySQL 3.23.52 with innodb transaction support: > 4 concurrent queries :- 257.36 ms > 40 concurrent queries :- 35.12 ms > Postgresql 7.2.2 > 4 concurrent queries :- 257.43 ms > 40 concurrent queries :- 41.16 ms I

Re: [HACKERS] pg_filedump

Alvaro Herrera <[EMAIL PROTECTED]> writes: > I'm trying to get something from pg_filedump. However, the version > published in sources.redhat.com/rhdb doesn't grok a lot of changes in > current CVS. I changed all those and made it compile... but looks like > that's only the easy part. I get bog

Re: [HACKERS] [GENERAL] Large databases, performance

On 7 Oct 2002 at 16:10, Manfred Koizar wrote: > if i'm not mistaken, a char(n)/varchar(n) column is stored as a 32-bit > integer specifying the length followed by as many characters as the > length tells. On 32-bit Intel hardware this structure is aligned on a > 4-byte boundary. That shouldn't b

Re: [HACKERS] [GENERAL] Large databases, performance

On Mon, 07 Oct 2002 15:07:29 +0530, "Shridhar Daithankar" <[EMAIL PROTECTED]> wrote: >Only worry is database size. Postgresql is 111GB v/s 87 GB for mysql. All >numbers include indexes. This is really going to be a problem when things are >deployed. Any idea how can it be taken down? Shridhar,

Re: Table spaces again [was Re: [HACKERS] Threaded Sorting]

> > >Can anybody please tell me in detail.(Not just a pointing towards TODO items) > >1) What a table space supposed to offer? > They allow you to define a maximum amount of storage for a certain set of data. They help you to define the location of data. They help you to define how much data can

Re: [HACKERS] Implicit Lock Row

On 5 Oct 2002 at 23:56, Antoine Lobato wrote: > > I currently develop an interface to simulate a indexed sequential file > management with PostgreSql. I must reproduce the same philosophy used of > control of locking of the records. > I seek a solution to lock and unlock implicitly a row of a

Table spaces again [was Re: [HACKERS] Threaded Sorting]

On 4 Oct 2002 at 21:13, Hans-Jürgen Schönig wrote: > Bingo = great :). > The I/O problem seems to be solved :). > > A table space concept would be top of the histlist :). > > The symlink version is not very comfortable and I think it would be a > real hack. > Also: If we had a clean table spac

Re: [HACKERS] Use of sync() [was Re: Potential Large Performance Gain in WAL synching]

Tom Lane <[EMAIL PROTECTED]> writes: > Doug McNaught <[EMAIL PROTECTED]> writes: > > In my understanding, it means "all currently dirty blocks in the file > > cache are queued to the disk driver". The queued writes will > > eventually complete, but not necessarily before sync() returns. I > >

Re: [HACKERS] Threaded Sorting

Threads are bad - I know ... I like the idea of a pool of processes instead of threads - from my point of view this would be useful. I am planning to run some tests (GEQO, AIX, sorts) as soon as I have time to do so (still too much work ahead before :( ...). If I had time I'd love to do somethi

[HACKERS] Implicit Lock Row

I currently develop an interface to simulate a indexed sequential file management with PostgreSql. I must reproduce the same philosophy used of control of locking of the records. I seek a solution to lock and unlock implicitly a row of a table. The locking of several rows, of the same table

Re: [HACKERS] Bad rules

Thankyou very much for your enlightened comment, it worked a treat. I do not seem to be able to find references to this kind of useful information in the postgresql online manual or in books such as bruce momjian's 'postgresql-introduction and concepts'. Where is this info to be found other than

Re: [HACKERS] Moving to PostGres

In article , Benjamin Stewart <[EMAIL PROTECTED]> wrote: >I am looking at moving our company away from MS SQL. Here's a good place to start: http://techdocs.postgresql.org/redir.php?link=/techdocs/sqlserver2pgsql.php -- http://www.spinics.net/linux/ -

[HACKERS] Case insensitive columns

I have a problem similar to that described by Shaw Terwilliger on 2001-03-14 (Subject: Case Insensitive CHECK CONSTRAINTs): I need some case insensitive char/varchar columns. A unique index on lower(col_name) wo <> ---(end of broadcast)--- TIP 1:

[HACKERS] Moving to PostGres

Hello, I am looking at moving our company away from MS SQL. Have been looking at DB2 and it looks to have some good features. Now wondering if POSTGRESQL could be a viable alternative. I have a few questions though; 1. What is the postgresql equiv to Stored procedures and can they be written in an

Re: [HACKERS] Threaded Sorting

Threads are not the best solutions when it comes to portability. A prefer a process model as well. My concern was that a process model might be a bit too slow for that but if we had processes in memory this would be wonderful thing. Using it for small amounts of data is pretty useless - I totall

Re: [HACKERS] Threaded Sorting

Greg Copeland wrote: >I wouldn't hold your breath for any form of threading. Since PostgreSQL >is process based, you might consider having a pool of sort processes >which address this but I doubt you'll get anywhere talking about threads >here. > >Greg > > > I came across the problem yesterda

Re: [HACKERS] Threaded Sorting

Bingo = great :). The I/O problem seems to be solved :). A table space concept would be top of the histlist :). The symlink version is not very comfortable and I think it would be a real hack. Also: If we had a clean table space concept it would be real advantage. In the first place it would be

Re: [HACKERS] Analysis of ganged WAL writes

Hannu Krosing <[EMAIL PROTECTED]> writes: > in an ideal world this would be 5*120=600 tps. > Have you any good any ideas what holds it back for the other 300 tps ? Well, recall that the CPU usage was about 20% in the single-client test. (The reason I needed a variant version of pgbench is that t

Re: [HACKERS] cross-posts (was Re: [GENERAL] Large databases,

On Mon, 2002-10-07 at 07:01, Michael Paesold wrote: > > On Sun, 2002-10-06 at 22:20, Tom Lane wrote: > > > Curt Sampson <[EMAIL PROTECTED]> writes: > > > > ... Avoiding cross-posting would be nice, since I am getting lots of > > > > duplicate messages these days. > > > > > > Cross-posting is a fac

Re: [HACKERS] cross-posts (was Re: [GENERAL] Large databases,

> On Sun, 2002-10-06 at 22:20, Tom Lane wrote: > > Curt Sampson <[EMAIL PROTECTED]> writes: > > > ... Avoiding cross-posting would be nice, since I am getting lots of > > > duplicate messages these days. > > > > Cross-posting is a fact of life, and in fact encouraged, on the pg > > lists. I sugge

Re: [HACKERS] cross-posts (was Re: [GENERAL] Large databases,

On Sun, 2002-10-06 at 22:20, Tom Lane wrote: > Curt Sampson <[EMAIL PROTECTED]> writes: > > ... Avoiding cross-posting would be nice, since I am getting lots of > > duplicate messages these days. > > Cross-posting is a fact of life, and in fact encouraged, on the pg > lists. I suggest adapting.

Re: [HACKERS] Analysis of ganged WAL writes

Tom Lane kirjutas E, 07.10.2002 kell 01:07: > > To test this, I made a modified version of pgbench in which each > transaction consists of a simple > insert into table_NNN values(0); > where each client thread has a separate insertion target table. > This is about the simplest transaction I

Re: [HACKERS] [GENERAL] Large databases, performance

On 3 Oct 2002 at 8:54, Charles H. Woloszynski wrote: > I'd be curious what happens when you submit more queries than you have > processors (you had four concurrent queries and four CPUs), if you care > to run any additional tests. Also, I'd report the query time in > absolute (like you did) a

Re: [HACKERS] Proposed LogWriter Scheme, WAS: Potential Large Performance Gain in WAL synching

> > Keep in mind that we support platforms without O_DSYNC. I am not > > sure whether there are any that don't have O_SYNC either, but I am > > fairly sure that we measured O_SYNC to be slower than fsync()s on > > some platforms. This measurement is quite understandable, since the current softw