esheets/catalog -d stylesheet.dsl -i
output-html -t sgml postgres.sgml
openjade:bookindex.sgml:2731:0:E: character data is not allowed here
openjade:bookindex.sgml:2732:66:E: document type does not allow element "ULINK"
here; missing one of "SEEIE", "SEEALSOIE", &quo
allowed by the
kernal. This is different story though, I think). So it seems the line
would be better looking at FD_SETSIZE in select.h.
Included is the proposed patch. Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
*** pgbench.c 22 Aug 2007 23:03:27 - 1.70
--- pgbench.c 25 Aug 2007 02
- Are you doing the development in working time or private time?
- Do your company encourage PostgreSQL development?
- What will help you to do more PostgreSQL development?
Each survey result will not be put in public unless an explicit
permission is given by the developer.
Best regards,
--
T
taining the newly
loaded data will be removed anyway."
Sounds great!
BTW, I noticed that "COPY, CLUSTER, B-Tree split logging improvements"
in Josh's presentation in Tokyo. Are they just internal changes and
are nothing to do with DBA's job?
--
Tatsuo Ishii
SRA OSS, I
on since I think this is valuable information for DBAs
who wish to migrate to 8.3.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
change conversion function's signature so that
we don't need to have the fixed conversion rate as Tom suggested.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Where are we on this?
>
> ---
>
> Tom Lane wrote:
Sorry for dealy.
> On Tue, May 29, 2007 20:51, Tatsuo Ishii wrote:
>
> > Thinking more, it striked me that users can define arbitarily growing
> > rate by using CFREATE CONVERSION. So it seems we need functionality to
> > define the growing rate anyway.
>
> Woul
'm
not talking about Unicode here). LATIN1 inclues English and several
european languages. EUC-JP includes English and Japanese etc. And
we specify encoding for char's property, not language, I would say the
configuration should be bound to an encoding.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
-
ware. Fortunately we have
several kinds of open source softwares for this pupose. Once I have
written a PostgreSQL C function envoking one of these software to do
the work and it works great with tsearch2.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Ok, probably we need to copy the English stemming rule to the one for
> > Japanese.
>
> Pardon my ignorance here, but is the concept of stemming even relevant
> to Japanese/Chinese/Korean? What little I know about ideog
> I would be surprised if C locale defaulted to anything except English.
Don't be surprised. The mechanism of collation is too simple for
Japanse Kanji, and locale is not usefull for Japanse anyway. That's
why Japanese installations of PostgreSQL tend to use C locale.
--
Tatsuo Ishii
> Tatsuo Ishii wrote:
>
> > japanese '{ja_JP, C}'
> >
> > How would we know C -> japanese?
> >
> You can't do that. You can't have different languages (not locales)
> mapping to the same 'tsearch language' because the stemmer
ve to?:
japanese '{ja_JP, C}'
How would we know C -> japanese?
Also I'm wondering how we could handle texts including Japanese and
English. It's very common in Japan.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 6: explain analyze is your friend
rk for initdb with locale C?
I'm worrying about that too.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
> > On Mon, May 28, 2007 at 10:23:42PM -0400, Tom Lane wrote:
> > > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > > I'm afraid we have to mke it larger, rather than smaller for 8.3. For
> > > > example 0x82f5 in SHIFT_JIS_2004 (new in 8.3) becom
> On Mon, May 28, 2007 at 10:23:42PM -0400, Tom Lane wrote:
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > I'm afraid we have to mke it larger, rather than smaller for 8.3. For
> > > example 0x82f5 in SHIFT_JIS_2004 (new in 8.3) becomes *pair* of 3
> &
ne an exact output size, if that
> seemed worthwhile because the potential growth rate was too extreme.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
004 (new in 8.3) becomes *pair* of 3
bytes UTF_8 (0x00e3818b and 0x00e3829a). See
util/mb/Unicode/shift_jis_2004_to_utf8_combined.map for more details.
So the worst case is now 6, rather than 3.
Can we add a column to pg_conversion which represents the "growth
rate"? This w
> * Tatsuo Ishii <[EMAIL PROTECTED]> [070515 21:19]:
>
> > As I proposed for many times, why don't we add message number to each
> > subject line in mail? For example like this:
> >
> > [HACKERS: 12345] Re: Not ready for 8.3
> >
> > This
> Tatsuo Ishii wrote:
> > > Stefan Kaltenbrunner wrote:
> > > >> They are not stable. The items should point to the archives, which are
> > > >> supposedly more stable. (I had already fixed one item in PatchStatus
> > > >> this morning
or example like this:
[HACKERS: 12345] Re: Not ready for 8.3
This way, we could always obtain stable (logical) pointer, without
reling on particular archival infrastructure.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 9: In versions
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > The message in question should be something like:
> > "COPY delimiter must be a single ASCII character"
>
> If we phrase it like that we should enforce it like that --- ie, reject
> high-bit-set characte
regards, tom lane
+1.
The message in question should be something like:
"COPY delimiter must be a single ASCII character"
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >> I think the best way to proceed is probably to fix this in HEAD but
> >> not back-patch it. During a dump and reload the encoding can be
> >> corrected to something safe.
>
> > Ok. Shall I go a
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Sigh. From the first day when JOHAB was supported (back to 7.3 days),
> > it should had not been in the server encodings. JOHAB's second byte
> > definitely contain 0x41 and above. *johab*.map just reflect the
> >
g it away.
Totally agreed here. I experienced throughput improvement by using
commit_delay too.
> An alternate mechanism that tells the client the commit is done when it
> hasn't hit disk is of no use for the applications I work with, so I
> haven't even been paying attention to
Patch committed. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> On 4/6/07, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> >
> >
> > BTW, is anybody working on enabling the fill factor to the tables used
> > by pgbench? 8.3 will introduce HOT, and I think adding the f
Patch committed. Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> The attached is a patch to optimize contrib/pgbench using new 8.3 features.
>
> - Use DROP IF EXISTS to suppress errors for initial loadings.
> - Use a combination of TRUNCATE and COPY to reduce WAL on creating
> the
> On Fri, 6 Apr 2007, Tatsuo Ishii wrote:
>
> > 1) latency log file format extention looks usefull (-x option).
> > 2) it seems the "cleanup feature" (-X option) was withdrawed by the
> > author, but the patches still include the feature. So I'm confuse
re
will make it easier to test HOT.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> > ---
> >
> > ITAGAKI Takahiro wrote:
> > > The attached is a patch to optimize contrib/pgbench using new 8.3
> > >
by the
author, but the patches still include the feature. So I'm confused.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> > ---
> >
> > Greg Smith wrote:
> > > This patch changes the way pgbe
ng would not help him in this case:
SELECT * FROM japanese_table ORDER BY t;
Also I don't understand what this is different to the problem when we
have a message catalogue which does not match the encoding.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
> Tatsuo Ishii wrote:
>
> > BTW, every encoding has its own charset. However the relationship
> > between encoding and charset are not so simple as Unicode. For
> > example, encoding EUC_JP correponds to multiple charsets, namely
> > ASCII, JIS X 0201, JIS X 0208
> Tatsuo Ishii wrote:
>
> > . I think we need to continute design discussion, probably
> > targetting for 8.4, not 8.3.
>
> The discussion came about because Andrew - Supernews noticed that chr()
> returns invalid utf8, and we're trying to fix all the bugs wi
k we need to continute design discussion, probably
targetting for 8.4, not 8.3.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
ve no grounds for complaining if the headers
> change incompatibly.
I thought PQescapeString() of 8.3 uses mbverify functions to make sure
that user supplied multibyte string is valid.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 6: explain analyze is your friend
S should be added too).
If there's no objection, patches for current will be posted for a
review (patches have been develpped by a Japanese developer, not me).
Comments and suggestions are welcome.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)--
s (a patch
> i'm not aware of, for example), is it considered as a todo for further
> releases or should i consider augmenting postgres in a way (if the
> latter, could you provide any pointers on how to proceed?)
You can always use CREATE CONVERSION for this kind of purpose.
Create your ow
s (a patch
> i'm not aware of, for example), is it considered as a todo for further
> releases or should i consider augmenting postgres in a way (if the
> latter, could you provide any pointers on how to proceed?)
You can always use CREATE CONVERSION for this kind of purpose.
Create your ow
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >> Related to this, when are we going to get the Japanese po files in the
> >> core distribution?
>
> > No idea. In my understanding, current message translating system has
> > serious problem if wron
roki Kataoka, chairman of JPUG has
same impression. Japanese po files are managed by JPUG and it would be
better to ask him or someone from JPUG who is responsible for Japanese
po files.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 7:
roki Kataoka, chairman of JPUG has
same impression. Japanese po files are managed by JPUG and it would be
better to ask him or someone from JPUG who is responsible for Japanese
po files.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 1
t should had not been in the server encodings. JOHAB's second byte
definitely contain 0x41 and above. *johab*.map just reflect the
fact. I think we should remove JOHAB from the server encodings list.
I'm afraid users who have JOHAB encoded databases get angry, though.
--
Ta
t should had not been in the server encodings. JOHAB's second byte
definitely contain 0x41 and above. *johab*.map just reflect the
fact. I think we should remove JOHAB from the server encodings list.
I'm afraid users who have JOHAB encoded databases get angry, though.
--
Ta
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > >> I'm confused. If this is exactly the same as EUC_JP, why do we need
> > >> any new code at all?
> >
> > > I said *encoding schema" is same, not the contents (character set) is
>
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >> I'm confused. If this is exactly the same as EUC_JP, why do we need
> >> any new code at all?
>
> > I said *encoding schema" is same, not the contents (character set) is
> > same. In another
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I would like to propose adding new character set "JIS X
> > 0213"(http://en.wikipedia.org/wiki/JIS_X_0213).
> > ...
> > Note that since encoding schema of EUC_JIS_2004 is exactly identical
> > to EUC_JP
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I would like to propose adding new character set "JIS X
> > 0213"(http://en.wikipedia.org/wiki/JIS_X_0213).
> > ...
> > Note that since encoding schema of EUC_JIS_2004 is exactly identical
> > to EUC_JP
ion changes, regression updates and bump up
catalog version.
After that I will develop conversion part(it will take several days).
comments, suggestions are welcome.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
jisx0213.patch
Description: Binary data
---(end of broadcast)---
> On 3/5/07, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> > From: "Nikolay Samokhvalov" <[EMAIL PROTECTED]>
> > > I've submitted patch for simple XPath 1.0 support (based on libxml2):
> > > http://archives.postgresql.org/pgsql-patches/2007-
From: "Nikolay Samokhvalov" <[EMAIL PROTECTED]>
Subject: [HACKERS] Re: [HACKERS] XQuery or XPathサポート
Date: Mon, 5 Mar 2007 14:51:43 +0300
Message-ID: <[EMAIL PROTECTED]>
> On 3/5/07, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> > Is there any plan for support
Is there any plan for supporting XQuery or XPath in 8.3?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that
Just for curiosity, I would like to ask you why you need to modify
pgbench. pgbench can accept custom SQL scripts...
P.S. HOT seems to be one of the greatest enhancements since PostgreSQL
was born!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Hi All,
>
> Here are some preliminary numbers wit
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > CVS HEAD doc won't compile due to broken mark up. Please someone
> > commit following patches if they are appropreate.
>
> Done.
Thanks.
> > Also please do not commit broken sgml files without trying to comp
CVS HEAD doc won't compile due to broken mark up. Please someone
commit following patches if they are appropreate.
Also please do not commit broken sgml files without trying to compile
them.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Index: array
CVS HEAD doc won't compile due to broken mark up. Please someone
commit following patches if they are appropreate.
Also please do not commit broken sgml files without trying to compile
them.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Index: array
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I looked into this more and I think I'm afraid the proposed solution
> > actually does not work for SQL functions. For example,
>
> > CREATE OR REPLACE FUNCTION foo(INTEGER, INTEGER) RETURNS INTEGER AS $$
>
chema
> search path.
actually does not work for SQL functions. For example,
CREATE OR REPLACE FUNCTION foo(INTEGER, INTEGER) RETURNS INTEGER AS $$
SET search_path To pg_catalog,public;
SELECT mod($1,$2);
$$ LANGUAGE sql SECURITY DEFINER;
If an attacker creates public.mod() to do something bad
Thanks. I'll look into this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> 3-gram is implemented as a contrib/pg_trgm. It currently uses GiST index,
> but may be enhanced with the GiN.
>
> Oleg
>
> On Sat, 17 Feb 2007, Tatsuo Ishii wrote:
>
> > Hi,
> >
> &g
Thanks. I'll look into this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> 3-gram is implemented as a contrib/pg_trgm. It currently uses GiST index,
> but may be enhanced with the GiN.
>
> Oleg
>
> On Sat, 17 Feb 2007, Tatsuo Ishii wrote:
>
> > Hi,
> >
> &g
KE '%bar%' type matching.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
g with range 0-7f? is "latin"? If so, it seems they
are exacty same as ASCII.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> > In our case, we added JAPANESE_STOP_WORD into english.stop then:
> > select to_tsvector(JAPANESE_STOP_WORD)
> > which returns words even they are in JAPA
ct to_tsvector(JAPANESE_STOP_WORD)
which returns words even they are in JAPANESE_STOP_WORD.
And with the patches the problem was solved.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Hi,
Currently tsearch2 does not accept non ascii stop words if locale is
C. Included patches should fix the problem. Patches against PostgreSQL
8.2.3.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
*** wordparser/parser.c~2007-01-16 00:16:11.0 +0900
--- wordparser/parser.c 2007-02-10 18:04
Ok, understood.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > One of our engineer claimed that double free bug itself is a
> > vulnerability, thus 8.2.1 release should be called as "security
> > release".
>
> [ shrug
Tom,
Is this a fix for security hole/vulnerability?
One of our engineer claimed that double free bug itself is a
vulnerability, thus 8.2.1 release should be called as "security
release".
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Log Message:
> ---
> Fix failure due to a
t; HEAD
> and 8.2 branches.
I have tested on a Linux box running PostgreSQL 8.2.1 (C locale,
EUC_JP encoding), and it worked great!
BTW, is your patch supposed to work with PostgreSQL 8.1?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> PS. Magnus, may I ask you to t
> I have some some doubts that any character greater than 0x7f is an alpha
> symbol.
> Is it simple assumption or workaround?
Yeah, it's a workaround. Since there's no concept other than
alpha/numeric/latin in tsearch2, Asian characters have to be fall in
one of them.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 6: explain analyze is your friend
.
> >> ! if (lc_ctype_is_c())
> >> ! {
> >> ! if (c > 0x7f)
> >> ! return 1;
>
> I have some some doubts that any character greater than 0x7f is an alpha
> symbol.
> Sorry for delay, I was on holidays :)
>
> Did you test patch on Windows platform?
No. I myself does not use Windows platform.
Do you have any concern on Windows regarding my patches?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Tatsuo Ishii wrote:
> > I have tested with local-e
Is there any reason for not back porting the fix into 8.1?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Log Message:
> ---
> Change Windows rename and unlink substitutes so that they time out after
> 30 seconds instead of retrying forever. Also modify xlog.c so that if
> it fai
I have tested with local-enabled environment and found a bug. Included
is the new version of patches.
Teodor, Oleg, what do you think about these patches?
If ok, shall I commit to CVS head?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Hi,
>
> Here are patches against tsearch2 with
etc. will not be called in case of C locale
since they are not working with it. Tested with the EUC_JP encoding
(should be working with any multibye encodings). Existing single byte
encodings should not be broken by the patches, I did not test though.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Index
I'd love to see your program. Could you please submit to -pacthes?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> I've written up a Warm Standby script as a .c program rather than
> scripts, to allow it to be portable and potentially shipped as part of
> PostgreSQL core.
>
> pg_
igure out which one is related to the item.
Any idea?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
with GIN.
> tsvector size should not be greater than 1Mb however.
Is this documented somewhere? Also I noticed that tsearch2 treats ":"
as a special character. Are there any special characters? If so where
are they documented?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---
So, I need to modify tsearch2
anyway (I know someone from Japan is working on this).
BTW, can tsearch2 handle ~70k words in a document?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
g how GIN scales.
> Why do not you use tsearch framework?
? I thought GIN is superior than tsearch2.
>From your GIN proposal posted to pgsql-hackers:
"The primary goal of the Gin index is a scalable full text search in
PostgreSQL"
What do you think?:-)
--
y elements, string_to_array seems to eat several Gig bytes of
memory. ~70k array elements means there are same number of words in a
document which is not too big in a large text IMO.
Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 1:
data. Is this normal?
This is PostgreSQL 8.2 beta1.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 6: explain analyze is your friend
t; log segments with bogus data. Is this normal?
I mean 4.6GB per day.
> This is PostgreSQL 8.2 beta1.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
>
> ---(end of broadcast)---
> TIP 6: explain analyze is your friend
>
od name for the variable that
> reflects the scaling factor? It seems awfully easy to confuse that with
> the TPS numbers that pgbench reports. Perhaps ":scale" or some such
> would be better.
I replaced all occurenes of "tps" to scale.
--
Tatsuo Ishii
SRA OSS, In
I'll look into this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> I have just realized that the recent patches in pgbench have altered its
> behavior in a way that destroys reproducibility of results --- I'm
> seeing reported TPS numbers about twice what they were before that.
>
ay with
> rtree?
Don't know. I just heard that they evaluated GIST and decided not to
go with it. I'll get back if I get more info.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 4: Have you searche
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> >>> Is there any reason for Rtree circle ops not being included in
> >>> PostgreSQL?
> >>
> >> rtree is going away (has gone away in HEAD
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Is there any reason for Rtree circle ops not being included in
> > PostgreSQL?
>
> rtree is going away (has gone away in HEAD awhile ago, in fact).
I know. I just want to make sure that there's any technical reason it
Hi,
Is there any reason for Rtree circle ops not being included in
PostgreSQL?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 6: explain analyze is your friend
Thanks. I have committed your patches.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Hi Tatsuo-san and folks,
>
> This is a fix in pgbench to handle empty lines in external scripts.
> The manual says
> | Empty lines and lines begging with "--" will be ignored.
> but AFAICS,
Also we will continue to support legacy version until
pgpool-II becomes stable enough.
Also you might want to add pgpool development site URL.
FYI, pgpool-II presentation material for PostgreSQL Anniversary Summit
can be obtained from:
http://www.sraoss.co.jp/event_sem
Good catch!
Thanks. I have committed your fix.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> I found a buffer overflow bug in contrib/pgbench.
> This occures when -c >= 2.
>
>
>
> The type of 'state' is CState*, so we should use state+1 or &state[1],
> not state
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > BTW, running long benchmark using pgbench on BIG tables easily causes
> > an integer overflow error in following SQLs:
>
> Right.
>
> > I'm inclined to change abalance, tbalance and bbalance column to
> &
d have posted patches and called for
discussion? I omit the step because a) pgbench is a contrib program,
b) the changes do not break the backward compatibility.
I always call for discussions for questionable part. (for example,
column type change proposal for pgbench tables).
--
Tatsuo Ishii
SRA
te tellers set tbalance = tbalance + :delta where tid = :tid;
update branches set bbalance = bbalance + :delta where bid = :bid;
I'm inclined to change abalance, tbalance and bbalance column to
BIGINT to avoid the error. Opinion?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
ommand now allows arithmetic calculations.
enjoy,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
; Hmm, what interface code are you talking about?
>
> I believe JDBC, for example, sets things inside the interface that would
> be broken by RESET CONNECTION. Here is a thread about it:
>
> http://archives.postgresql.org/pgsql-patches/2005-01/msg00029.php
I think we had simi
iscussion in Japanese managed by JPUG) have subject headers like
this:
[pgsql-jp: 34814] pgpool 2.5 released
By using this method our TODO list can referer emais "logical" id
(34814 in this case) which is independent on archive URL.
Archive URL is something like a &quo
I'm disappointed.
Can you point out past discussion for this?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Mario Weilguni wrote:
> > Will this patch make it into 8.2?
> > http://archives.postgresql.org/pgsql-patches/2004-12/msg00228.php
> >
> > It's a really nice f
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > Interesting. We (some Japanese companies including SRA OSS,
> > > Inc. Japan) did some PG scalability testing using a Unisys's big 16
> > > (physical) CPU machine and found PG scales up to 8 CPUs.
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > Interesting. We (some Japanese companies including SRA OSS,
> > Inc. Japan) did some PG scalability testing using a Unisys's big 16
> > (physical) CPU machine and found PG scales up to 8 CPUs. However
> > beyon
is available at the
moment. Please use some automatic translation services)
Evalution environment was:
PostgreSQL 8.1.2
OSDL DBT-1 2.1
Miracle Linux 4.0
Unisys ES700 Xeon 2.8GHz CPU x 16 Mem 16GB(HT off)
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
901 - 1000 of 1697 matches
Mail list logo
