ou've added information on
btree strip log records, which anables to produce corresponding
incremental logs from the full page writes.
2007/5/21, Tom Lane <[EMAIL PROTECTED]>:
Koichi Suzuki <[EMAIL PROTECTED]> writes:
> As replied to "Patch queue triage" by Tom, he
I'd be very grateful if this patch can be considered again.
Best Regards;
--
-
Koichi Suzuki
diff -cr pgsql_org/src/backend/access/transam/xlog.c
pgsql/src/backend/access/transam/xlog.c
*** pgsql_org/src/backend/access/transam/xlog.c 2007-05-02 15:56:38.0
+0900
---
ullpage_optimization quite baffling
and I think our general user base will find it even more so. Now that I have
Koichi's explanation of the problem, I vote for simply slaving this to the
PITR settings and not having a separate option at all.
Could I have more specific suggestion on this
://www.postgresql.org/docs/faq
--
-
Koichi Suzuki
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
log-shipping and I agree.
If we compare compression with gzip or other general purpose
compression, compression ratio, CPU usage and I/O by pg_compresslog are
all quite better than those in gzip.
Please let me know if you intended defferently.
Regards;
--
-
Koichi Suzuki
--
o make
redo routines confused with the dummy full page writes, as
Simon suggested. So far, it works fine.
Yes, Tom didn't like "LSN replacing" eighter. I withdraw my concern
regarding pg_decompresslog.
Your work in this area is extremely valuable and I hope
gfoundry; with the hope
> that it would be merged to contrib or core in 8.4. Frankly the
> compress/decompress code needs work anyway before it could be
> merged (eg, I noted a distinct lack of I/O error checking).
>
> regards, tom lane
>
--
-
space saved by omitting full pages.
Agreed. I don't want to start touching something that works so well.
We've been thinking about doing this for at least 3 years now, so I
don't see any reason to baulk at it now. I'm happy with Koichi-san's
patch as-is, assuming f
cord position
during replay ?
Add simple short WAL records in pg_compresslog like: advance LSN by 8192
bytes.
Andreas
--
-
Koichi Suzuki
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
logs which
pg_compresslog produces. For recovery, we have to restore LSN as the
original WAL. Pg_decompresslog restores removed full page writes as a
dumm records so that recovery redo functions won't be confused.
Regards;
Andreas
--
-----
Koichi Suzuki
---(e
to be a winner even if it just does not
degrade performance.
--
Koichi Suzuki
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
The score below was taken based on 8.2 code, not 8.3 code. So I don't
think the below measure is introduced only in 8.3 code.
Tom Lane wrote:
> Koichi Suzuki <[EMAIL PROTECTED]> writes:
>> For more information, when checkpoint interval is one hour, the amount
>> of th
it's reasonable measure.
Again, in my proposal, it is not the issue to increase run time
performance. Issue is to decrease the size of archive log to save the
storage.
Regards;
Tom Lane wrote:
> Koichi Suzuki <[EMAIL PROTECTED]> writes:
>> My proposal is to remove unnecessary f
.
Regards;
Simon Riggs wrote:
On Tue, 2007-04-03 at 19:45 +0900, Koichi Suzuki wrote:
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
Thank you very much for including. Attached is an update of the
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
Thank you very much for including. Attached is an update of the patch
according to Simon Riggs's comment about GUC name.
Regards;
--
K
Here's third revision of WAL archival optimization patch. GUC
parameter name was changed to wal_add_optimization_info.
Regards;
--
Koichi Suzuki
20070403_pg_lesslog.tar.gz
Description: application/gzip
---(end of broadcast)---
TIP
to
indicate number of full page writes included in the record.
In my proposal, this unused bit is used to mark that full page
writes must not be removed at offline optimization by pg_compresslog.
Regards;
--
--
Koichi Suzuki
--
Koichi Suzuki
---(end of broadcast)
thread to continue my post. Sorry for confusion.
Please refer to the original thread about this discussion.
Best Regards;
--
------
Koichi Suzuki
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Hi,
Here's a patch reflected some of Simon's comments.
1) Removed an elog call in a critical section.
2) Changed the name of the commands, pg_complesslog and pg_decompresslog.
3) Changed diff option to make a patch.
--
Koichi Suzuki
pg_lesslog.tgz
Description: B
sh recovery", "needed in archive recovery" and so on.
I don't insist these names. It's very helpful if you have any
suggestion to reflect what it really means.
Regards;
--
Koichi Suzuki
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Hi, Here're some feedback to the comment:
Simon Riggs wrote:
On Wed, 2007-03-28 at 10:54 +0900, Koichi Suzuki wrote:
As written below, full page write can be
categolized as follows:
1) Needed for crash recovery: first page update after each checkpoint.
This has to be kept in WAL.
2) N
Simon;
Thanks a lot for your comments/advices. I'd like to write some feedback.
Simon Riggs wrote:
On Tue, 2007-03-27 at 11:52 +0900, Koichi Suzuki wrote:
Here's an update of a code to improve full page writes as proposed in
http://archives.postgresql.org/pgsql-hackers/2007-01/ms
oposal
but still would like to hear comments/opinions/advices.
Regards;
--
Koichi Suzuki
pg_lesslog.tgz
Description: Binary data
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
two commands can be treated as contrib and the patch itself does
work if WAL is simply copied to the archive directory.
Regards;
Koichi Suzuki
Tom Lane wrote:
> Koichi Suzuki <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Doesn't this break crash recovery on PITR sla
Tom Lane wrote:
> Koichi Suzuki <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Doesn't this break crash recovery on PITR slaves?
>
>> Compressed archive log contains the same data as full_page_writes off
>> case. So the influence to PIT
Tom Lane wrote:
> Koichi Suzuki <[EMAIL PROTECTED]> writes:
>> Here's an idea and a patch for full page writes improvement.
>
>> Idea:
>> (1) keep full page writes for ordinary WAL, make them available during
>> the crash recovery, -> recovery from in
to make LSN consistent.
Included is a patch for this as well as archive and restore command source.
Patch is very small and I hope this to be included in 8.3.
--
Koichi Suzuki
pg_lesslog.tar.gz
Description: application/gzip
---(end of broadcast)---
TIP
be big SQL against big dataset is
another example to show the effect.
I also agree that we need much more study to show the effect of 64bit
TID (and perhaps CID). Based on the patch I posted, I'll continue my
effort and also post the results for discussion.
Best Regards;
Tom Lane wrote:
ering if it would be more
interesting to try them against CVS rather than 8.0.3 (and if it would
be easy to port :)?
Mark
--
---
Koichi Suzuki
Open Source Engineeering Departmeent,
NTT DATA Intellilink Corporation
Phone: +81-3-5566-9628 WWW:
ed is a result of pgbench with 64bit patch PostgreSQL (base is
8.0.1). Benchmark machine is dual opteron (1.4GHz, 1MB cache each) with
8GB of memory and 120GB of IDE hard disk.
Koichi Suzuki wrote:
>> I have some experimeltal data about this extension. I will gather it
>> an
Hi,
Attached is a result of pgbench with 64bit patch PostgreSQL (base is
8.0.1). Benchmark machine is dual opteron (1.4GHz, 1MB cache each) with
8GB of memory and 120GB of IDE hard disk.
Koichi Suzuki wrote:
> I have some experimeltal data about this extension. I will gather it
> an
I have some experimeltal data about this extension. I will gather it
and post hopefully this weekend.
Tom Lane wrote:
> Koichi Suzuki <[EMAIL PROTECTED]> writes:
>
>>Here're a couple of patches for PostgreSQL 64bit support. There're just
>>two extension t
Hi, all,
I have posted a couple of patches with regard to 64bit environment
support to PATCHES ml. It expands size of shared memory to 64bit space
and extends XID to 64bit. Please take a look at it.
--
---
Koichi Suzuki
Open Source Engineeering
re welcome.
--
-------
Koichi Suzuki
Open Source Engineeering Departmeent,
NTT DATA Intellilink Corporation
Phone: +81-3-5566-9628 WWW: http://www.intellilink.co.jp
--
Proposal: 64bit Extension in Postgr
34 matches
Mail list logo
