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.
Would it make sense to define just the longest
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:
I just rearranged the code
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
---(end
and it works great with tsearch2.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(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
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 doesn't know
that a specific word is in english or japanese. So you have two
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
SRA OSS, Inc
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 ideographic
languages suggests it wouldn't
that too.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
?
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
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
bytes UTF_8 (0x00e3818b and 0x00e3829a). See
/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 would reduce the rate for most encodings much smaller than
6.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end
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
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
bytes UTF_8 (0x00e3818b and 0x00e3829a). See
util
* 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 way, we could always obtain stable (logical) pointer, without
reling
reling on particular archival infrastructure.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(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
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). Really it would be much nicer to have links using the
Message-Id but I
.
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?
http://www.postgresql.org/docs
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 characters.
But I'm a bit hesitant to do so, because
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 ahead and remove JOHAB in HEAD?
+1 for me
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
fact. I think we should remove JOHAB from
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 no-commit-wait.
Agreed too.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
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 feature
will make it easier to test HOT
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 confused.
The patch I sent to the mailing list pulled
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 accounts table
, 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 pgbench outputs its latency log files so that
every transaction gets
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
features.
- Use DROP IF EXISTS to suppress errors
EUC_JP correponds to multiple charsets, namely
ASCII, JIS X 0201, JIS X 0208 and JIS X 0212. So a function which
returns a code point is not quite usefull since it lacks the charset
info. I think we need to continute design discussion, probably
targetting for 8.4, not 8.3.
--
Tatsuo Ishii
SRA OSS, Inc
Tatsuo Ishii wrote:
SNIP. 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 with invalid
utf8 in the system
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 and JIS X 0212. So a function which
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
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
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)---
TIP 6: explain analyze
(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 own conversion map between SJIS -- EUC or UT-8.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 9
(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 own conversion map between SJIS -- EUC or UT-8.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 3
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.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 4
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.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 2
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: if posting/reading
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: You can help
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 wrong locale and encoding is provided(has this
issue been solved
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 word, characters included in EUC_JP are not same
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)---
TIP 4: Have you searched our
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, we can reuse existing encoding routines defined in
utls/mb
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, we can reuse existing encoding routines defined in
utls/mb
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 word, characters included in EUC_JP are not same as
EUC_JIS_2004
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
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 supporting XQuery or XPath in 8.3?
I've submitted patch
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-03/msg00088.php
But contrib/README.xml2 stated:
This version
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.sgml
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.sgml
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 compile
them.
Some committers are using DocBook
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 with the HOT 4.0
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,
Is anybody working on implementing n-gram search
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,
Is anybody working on implementing n-gram search
executing foo(), his
attack will succeed since calling to mod() is resolved in the plan
time thus it will be resolved to public.mod, rather than
pg_catalog.mod.
Am I missing something?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 4
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 $$
SET search_path To pg_catalog,public;
SELECT mod
matching.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
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 JAPANESE_STOP_WORD.
And with the patches the problem was solved.
Pls, show your configuration
);
lexize
{}
Russian characters with UTF8 take two bytes.
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 JAPANESE_STOP_WORD.
And with the patches the problem was solved.
--
Tatsuo Ishii
SRA
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... ] AFAICS the crashing bugs we fixed in 8.2.1 can't
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 accessing an already-freed
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 test under Windows? Thank you.
--
Teodor Sigaev E-mail: [EMAIL
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-enabled environment
.
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 3
in
one of them.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 6: explain analyze is your friend
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 CVS head. Currently
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_standby is designed
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
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?:-)
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 5: don't
, 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
.
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
---(end of broadcast)---
TIP 1: if posting/reading through Usenet
, 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: if posting
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
---(end of broadcast
. 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
occurenes of tps to scale.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(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
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.
I'd love to say we did
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
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
had not been supported for long time
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 awhile ago, in fact).
I know. I just want to make sure that there's any technical
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 searched our list archives?
http://archives.postgresql.org
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, it cannot accept empty lines and exit
/pgpool_feat_and_devel.pdf
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
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 + sizeof(*state)
*** pgbench.c Mon Jul 31
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
;
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
---(end of broadcast)---
TIP 9: In versions
the backward compatibility.
I always call for discussions for questionable part. (for example,
column type change proposal for pgbench tables).
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please
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
BIGINT to avoid the error. Opinion?
No. The problem
is a thread about it:
http://archives.postgresql.org/pgsql-patches/2005-01/msg00029.php
I think we had similar problem with client encoding and solved it by
using parameter status. Why don't we solve the JDBC problem in the
same way?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
accidentaly and is not convenitent for this kind of usage IMO.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
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
beyond 8 CPU PG does not scale anymore. The result
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 feature, would be extremly useful with tools
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
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
beyond 8 CPU PG does not scale anymore. The result can
Tatsuo, are you planning to add this to CVS HEAD?
Yes, I would like to add if there's no objection.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---
Tatsuo Ishii wrote:
I have attached pgrowlocks tested under current
Tatsuo Ishii wrote:
Tatsuo, are you planning to add this to CVS HEAD?
Yes, I would like to add if there's no objection.
I have heard no comment, and it looks useful, so please add it at your
convenience.
Ok, done.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Tatsuo Ishii [EMAIL PROTECTED] writes:
I don't mind having encoding conversions be named within schemas,
but I propose that any given encoding pair be allowed to have only
one default conversion, period, and that when we are looking for
a default conversion we find it by a non-namespace
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm sure we need more than one default conversion for encoding A and
B. For example, different vendors provide different conversion maps
for SJIS and UTF-8. M$ has its own and Apple has another one, etc. The
differences are not huge but some
such as LATIN* and SJIS.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
then that's a bug.)
Then why do we have CREATE DEFAULT CONVERSION command at all?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
901 - 1000 of 1607 matches
Mail list logo
