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
Hi,
(B
(BI understand this is very old topics but ...
(BI tried to find where such lock mark is defined in each tuple on disk, but I
(Bfailed to find such definition in include/access/htup.h. Only the bit
(Brelevant to lock is HEAP_XMAX_UNLOGGED and I understand this bit is used only
(Bwhen
will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
--
Koichi Suzuki
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
Koichi Suzuki wrote:
I've once proposed a patch for 64bit transaction ID, but this causes
some overhead to each tuple (XMIN and XMAX).
Did you check performance on 32-bit or 64-bit systems and 64-bit binary
version of PGSQL? I think
.
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
proposed command-line syntax.
Thoughts?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
in archive
recovery, pg_core can call some backend to re-compress the archive log
for later use.
I'm not sure if archive_commend argument works in this scene too, but
very sceptical not.
Any further thoughts?
-
Koichi Suzuki
2008/10/25 Charles Duffy [EMAIL PROTECTED]:
In the absence
is done by posix_fadvise() as proposed in
index scan improvement.
Details of the implementation will be found in README file in the material.
--
--
Koichi Suzuki
pg_readahead_20081028.tar.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers
for research works.So far, I think it is reasonable to keep
improving specific code.
I'd like to hear some more about these. I'm more than happy to write
all the code inside PG core to avoid overhead to create another
process.
---
Koichi Suzuki
2008/10/29 Gregory Stark [EMAIL PROTECTED]:
Simon
the code is doing. Prefetch function returns LSN
where prefetch was performed. Redo routine has to call prefetch if
it is going to read WAL record beyond this.
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
format as
2. will help to simplify this as well.
2008/10/28 Heikki Linnakangas [EMAIL PROTECTED]:
Gregory Stark wrote:
Koichi Suzuki [EMAIL PROTECTED] writes:
This is my first proposal of PITR performance improvement for
PostgreSQL 8.4 development. This proposal includes readahead
compressed with pg_compresslog. I'll
test if it's okay in the case full_page_writes=off.
Anyway, I'd like to keep my proposal for 8.4 and continue the test and
evaluation to report to the mailing list.
I'll also change the whole code to run in the core.
---
Koichi Suzuki
2008/10/29 Simon
.
If we invoke posix_fadvise() to the blocks already in the kernel
cache, this call will just do nothing but consume some overhead in the
kernel. I think duplicate removal saves more.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
--
Koichi
[EMAIL PROTECTED]:
On Thu, 2008-11-27 at 21:04 +0900, Koichi Suzuki wrote:
We ran the
benchmark for on hour with chekpoint timeout 30min and completion_target 0.5.
Then, collected all the archive log and run PITR.
--+++---
WAL
that got eaten by the
message size limit?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers
for it, but it feels too wacky even
after Heikki and I agreed it was required. Do we still think that?
* locking correctness around flat file refresh still not enabled
* need some discussiona round how to handle max_connections changes
cleanly.
--
--
Koichi Suzuki
--
Sent via pgsql-hackers
Thank you for your advise. I'll edit the Wiki page.
2008/12/3 Pavan Deolasee [EMAIL PROTECTED]:
On Wed, Dec 3, 2008 at 11:00 AM, Koichi Suzuki [EMAIL PROTECTED] wrote:
Hi,
I found that no one is registered as hot standby reviewer. I'd like
to review the patch, mainly by testing
Agreed.
I borrowed WAL parsing code from XLogdump and I think WAL parsing
should be another candidate.
2008/12/3 Fujii Masao [EMAIL PROTECTED]:
Hi,
On Thu, Nov 27, 2008 at 9:04 PM, Koichi Suzuki [EMAIL PROTECTED] wrote:
Please find enclosed a revised version of pg_readahead and a patch
in this
case with no modification.
2008/12/4 Simon Riggs [EMAIL PROTECTED]:
On Wed, 2008-12-03 at 14:22 +0900, Koichi Suzuki wrote:
There's clearly a huge gain using prefetch, when we have
full_page_writes = off. But that does make me think: Why do we need
prefetch at all if we use full page
Appreciate for their contributions. Congratulations all!
Koichi Suzuki
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers
upload the new version ASAP.
Warmest Regards;
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
upload the new version ASAP.
Warmest Regards;
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thank you very much for the advice. Yes I think it should go to
announce. I will post a message.
--
Koichi Suzuki
2010/2/12 Karl Denninger k...@denninger.net:
Joshua D. Drake wrote:
On Thu, 2010-02-11 at 23:39 +0900, Koichi Suzuki wrote:
Dear Folks;
A very serious bug
each WAL record and whole WAL segment.
--
Koichi Suzuki
2010/2/12 Koichi Suzuki koichi@gmail.com:
Thank you very much for the advice. Yes I think it should go to
announce. I will post a message.
--
Koichi Suzuki
2010/2/12 Karl Denninger k...@denninger.net:
Joshua D
, I'm using conventional BTREE, btree_gin and btree_gist for
the test, as well as 2PC and savepoint.
Any information is welcome.
Thank you very much in advance;
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
to generate GIN-related WALs.
Thank you very much;
--
Koichi Suzuki
2010/4/14 Alvaro Herrera alvhe...@commandprompt.com:
Koichi Suzuki escribió:
Hi,
Does anyone know how to generate the following WAL records from psql?
I'm now fixing pg_lesslog, which I reported a bug. Now code
Thanks for encouraging comment. I'm still struggling to generate
remaing WAL records.
--
Koichi Suzuki
2010/4/14 Simon Riggs si...@2ndquadrant.com:
On Wed, 2010-04-14 at 11:13 +0900, Koichi Suzuki wrote:
Thank you for a great advice. I successfully generated all the WAL
records
you very much in advance;
--
Koichi Suzuki
2010/4/15 Bruce Momjian br...@momjian.us:
Kevin Grittner wrote:
Koichi Suzuki koichi@gmail.com wrote:
2010/4/14 Simon Riggs si...@2ndquadrant.com:
It would be a very useful test case to publish.
I'm still struggling to generate
be included in contrib module if it is ported to PostgreSQL 9.1.
Best Regards;
--
Koichi Suzuki
# pg_lesslog is a project to compress large WAL segments when they're
stored and restore then for recovery.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
this two years ago, recovery speed was as good as
those with full page image, depending upon application and tuning, of
course.
This is a separate tool and can be used in various scenes.
Regards;
--
Koichi Suzuki
2010/5/13 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:
Tom Lane t
transfer to transfer and it is not simple to handle.
Regards;
--
Koichi Suzuki
2010/5/13 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp:
Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Yes, I would love to get this into /contrib for PG 9.1!
How much are people
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/msg01491.php
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) Needed
have any
suggestion to reflect what it really means.
Regards;
--
Koichi Suzuki
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
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: Binary data
to continue my post. Sorry for confusion.
Please refer to the original thread about this discussion.
Best Regards;
--
--
Koichi Suzuki
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
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)---
TIP 5: don't forget to increase your free space map settings
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 1
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;
--
Koichi
.
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
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 full page writes (they are needed
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 the archived log size was as follows
not
degrade performance.
--
Koichi Suzuki
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
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
---(end of broadcast
short WAL records in pg_compresslog like: advance LSN by 8192
bytes.
Andreas
--
-
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
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 further extensive testing will be carried out on
it during beta.
--
-
Koichi Suzuki
---(end of broadcast
before it could be
merged (eg, I noted a distinct lack of I/O error checking).
regards, tom lane
--
-
Koichi Suzuki
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http
. 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 my comments are
not discouraging.
Thank you
Andreas
--
-
Koichi Suzuki
---(end
, 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
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
in WAL, and making the recovery able to
skip dummy records. This I would do unconditionally.
Andreas
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--
-
Koichi
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?
Regards;
--
-
Koichi Suzuki
---(end
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
--- pgsql/src/backend/access/transam/xlog.c 2007-05
Sorry for late responce due to very long vacation season in Japan.
Tom Lane wrote:
* Re: [PATCHES] [HACKERS] Full page writes improvement, code update
/Koichi Suzuki/
I feel that we have to insist that this be modified to not create
any WAL
bloat in the pre-compression form
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, here's simplified patch to
mark WAL record
pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
-hackers
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
If the version of the master and the slave is different and we'd still
like to allow log shipping replication, we need a negotiation if WAL
format for the two is compatible. I hope it is not in our scope
and I'm worrying too much.
2008/6/5 Tom Lane [EMAIL PROTECTED]:
Koichi Suzuki [EMAIL
implementation.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
--
Koichi Suzuki
--
Sent via pgsql-hackers
Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hi,
In GiST, I found that after the crash recovery, NSN and right page link
are initialized. We can search all the records in this case but
performance may become a little worse because we cannot traverse leaves.
I'm not sure if it is preffered behavior.
--
Koichi Suzuki
Hi,
Does anybody have an information about GiST index benchmark? I'm
planning to run GiST benchmark and analyze WAL structure to see PG's
dynamic behavior.
Regards;
--
Koichi Suzuki
---(end of broadcast)---
TIP 3: Have you checked our
://www.sigaev.ru/cvsweb/cvsweb.cgi/ftsbench/
and several others, based on it.
Koichi Suzuki wrote:
Hi,
Does anybody have an information about GiST index benchmark? I'm
planning to run GiST benchmark and analyze WAL structure to see PG's
dynamic behavior.
Regards;
--
Koichi
Oleg;
Thanks for the information. I'll try your code.
2007/12/20, Oleg Bartunov [EMAIL PROTECTED]:
On Thu, 20 Dec 2007, Koichi Suzuki wrote:
I'm trying to run some GiST activities and see XLOG record structure.
Koichi, I tested update speed of GiST and GIN
http://www.sai.msu.su/~megera
Hi,
I've ported pg_lesslog to PostgreSQL 9.0 and I'm testing it.
I'm not successful to produce the following WAL records.
XLOG_HEAP_INIT_PAGE
XLOG_BTREE_REUSE_PAGE
XLOG_GIST_PAGE_DELETE
XLOG_RELMAP_UPDATE
Any suggestions are welcome.
Thank you very much;
--
Koichi Suzuki
--
Sent via
and 8.4, version 1.4.1
is available.
Toward the final release, I will continue to add the test scripts to
test as many types of WAL record as possible.
Regards;
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Hmmm, it's really like pg_readahead needs to be included in the core.
I don't think it's a big work and will try to do this.
2008/12/9 Fujii Masao masao.fu...@gmail.com:
Hi,
On Mon, Dec 8, 2008 at 2:54 PM, Koichi Suzuki koichi@gmail.com wrote:
I understood your point. In the case
I'm now writing v3 patch of PITR improvement, to work with sync.rep
and Hot Standby.Would like to change the thread.
2008/12/12 Pavan Deolasee pavan.deola...@gmail.com:
On Fri, Dec 12, 2008 at 9:08 AM, Koichi Suzuki koichi@gmail.com wrote:
Hmmm, it's really like pg_readahead needs
not exist.
We still need a patch to work this with syncronous replication, which
will be posted by the end of this week.
Regards;
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
pglesslog and its
authors.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
--
Koichi
Sorry, I didn't attatch the patch file. This is the second try.
2009/1/12 Koichi Suzuki koichi@gmail.com:
This is V4 patch to improve file read during startup for review.
Basic algorithm is same as V3 but works with Gregory's fadvise patch.
http://archives.postgresql.org/pgsql-hackers
br...@momjian.us:
Koichi Suzuki wrote:
Hi,
I have no intention to make pglesslog to conflict to PostgreSQL
license. Any advice is welcome to make pglesslog available without
any license concern.
I certainly have no concerns.
I've a question and ideas.
Bruce's modification directly
Pg_readahead uses posix_fadvise, which is included in Greg's patch and
I've already posted pg_readahead patch integrated into the core.
Integration with snc.rep. will be a separate patch which will be
posted in a couple of days.
2009/1/14 Bruce Momjian br...@momjian.us:
Koichi Suzuki wrote
Hi,
It's simply because we should not refer to system catalog during the recovery.
2009/1/25 Gregory Stark st...@enterprisedb.com:
Koichi Suzuki koichi@gmail.com writes:
Please find enclosed 2nd patch of pg_readahead which include a patch
to bufer manager to skip prefetch of pages
Hi,
This is also a reply to your latest post.I'm replying to the older
one because I need original text.
2009/1/26 Koichi Suzuki koichi@gmail.com:
Hi,
It's simply because we should not refer to system catalog during the recovery.
This is the reason why I didn't use PrefetchBuffer
,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
--
Koichi Suzuki
--
Sent via
Hi,
My reply to Gregory's comment didn't have any objections. I believe,
as I posted to Wiki page, latest posted patch is okay and waiting for
review.
2009/2/24 Robert Haas robertmh...@gmail.com:
On Sun, Jan 25, 2009 at 7:15 AM, Gregory Stark st...@enterprisedb.com wrote:
Koichi Suzuki
Appreciate for your kind help!
2009/3/3 Fujii Masao masao.fu...@gmail.com:
On Tue, Mar 3, 2009 at 1:47 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi Suzuki-san,
On Thu, Feb 26, 2009 at 5:03 AM, Koichi Suzuki koichi@gmail.com wrote:
My reply to Gregory's comment didn't have any
=1000310
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
if malloc()
fails (OOM). In this case, possible way could be to skip whole
readahead, although the rest of the recovery may fail because of the
memory shortage.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing
-hackers
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Sorry I see the comment. I'll continue the work to fulfill the comment.
2009/3/17 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Koichi Suzuki wrote:
I believe all the issues pointed out in
http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php as
been covered
with
full_page_writes off, while the physical log is still available in the
crash recovery, maintaining the crash recovery chance.
Comments, questions and any input is welcome.
-
Koichi Suzuki, NTT Open Source Center
--
Koichi Suzuki
---(end of broadcast
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 inconsistent pages which can be
made at the crash,
(2
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 PITR slaves is the same as full_page_writes off.
Right. So what
)zip'ing the WAL files in the archive. I quick test
on my laptop shows over a 4x reduction in size. Presumably that'd be
even larger if you increased the size of WAL segments.
On Jan 29, 2007, at 2:15 AM, Koichi Suzuki wrote:
This is a proposal for archive log compression keeping physical log
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 slaves?
Compressed archive log contains the same data
|g)zip'ing the WAL files in the archive. I quick
test on my laptop shows over a 4x reduction in size. Presumably that'd
be even larger if you increased the size of WAL segments.
On Jan 29, 2007, at 2:15 AM, Koichi Suzuki wrote:
This is a proposal for archive log compression keeping physical log
into your compression ratio...
Have a nice day,
--
Koichi Suzuki
---(end of broadcast)---
TIP 6: explain analyze is your friend
are concerned
about fullpage overhead.
Andreas
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--
Koichi Suzuki
---(end of broadcast
but still would like to hear comments/opinions/advices.
Regards;
--
Koichi Suzuki
pg_lesslog.tgz
Description: Binary data
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http
HI,
Although xml2 was announced to be removed from 8.4, I found 8.4beta1
documentation has xml2 description. Does it mean that xml2 is
available in 8.4 as well?
--
--
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
Josh;
I belive this is an important agenda too, though I'm not sure if we can assing
90minutes to him. We need to organize the schedule shortly.
From XC, we will present progress, release schedule and further technical
challanges, including adding/removing nodes on-the-fly and HA feature.
Hi,
This is Koichi. I'm joining the summit. I've heard at least two or
more people will join from NTT.I'm expecting a couple of people
from EDB too.
Regards;
--
Koichi Suzuki
2012/2/29 Josh Berkus j...@agliodbs.com:
All,
First, I've added a wiki page:
http
Robert;
Thank you very much for your advice. Indeed, I'm considering to
change the license to PostgreSQL's one. It may take a bit more
though...
--
Koichi Suzuki
2010/12/15 Robert Haas robertmh...@gmail.com:
On Tue, Dec 7, 2010 at 3:23 AM, Koichi Suzuki koichi@gmail.com wrote
At present, XC does not seem to need locks to maintain cluster-wide
integrity because it is maintained centrally in GTM. If application
needs to do this, for example, to synchronize between different
clusters, XC needs this capability obviously.
--
Koichi Suzuki
2011/1/11 Tatsuo Ishii
;
---
Koichi Suzuki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thank you Joachim;
Yes, and the current patch requires the original (publisher)
transaction is alive to prevent RecentXmin updated.
I hope this restriction is acceptable if publishing/subscribing is
provided via functions, not statements.
Cheers;
--
Koichi Suzuki
2010/12/6 Joachim
We may need other means to ensure that the snapshot is available on
the slave. It could be a bit too early to use the snapshot on the
slave depending upon the delay of WAL replay.
--
Koichi Suzuki
2010/12/7 Tom Lane t...@sss.pgh.pa.us:
marcin mank marcin.m...@gmail.com writes:
On Sun
This is what Postgres-XC is doing between a coordinator and a
datanode.Coordinator may correspond to poolers/loadbalancers.
Does anyone think it makes sense to extract XC implementation of
snapshot shipping to PostgreSQL itself?
Cheers;
--
Koichi Suzuki
2010/12/7 Stefan
;
---
Koichi Suzuki
2014-06-02 7:22 GMT+09:00 Mikko Tiihonen mikko.tiiho...@nitorcreations.com:
Hi,
Currently the criteria on updating the F/B protocol is undefined. This makes
it hard to update the protocol going forward. It makes it also hard to write
library/driver/application implementations
1 - 100 of 101 matches
Mail list logo
