end Sync
message (because it is required in extended protocol), 4)Execute
unnamed portal created in #1.
If this is true, that means unnamed portal execution and named portal
execution cannot be mixed unless they are inside an explicit
transaction. IMO this should be described in the document.
--
T
g:
if ((nbytes + obj_desc->offset) > MAX_LARGE_OBJECT_SIZE)
elog(ERROR, "invalid read request size: %d", nbytes);
> * At inv_truncate(), variable "off" is re-defined to int64. Is it really
> needed
> change? All its usage is to sto
as been already explained in upthread:
http://archives.postgresql.org/pgsql-hackers/2012-09/msg00447.php
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> 2012/9/22 Tatsuo Ishii :
>> Tom, Kaigai,
>>
>>> Kohei KaiGai writes:
>>>> Tom, could you give us a suggestion which manner is better approach;
>>>> whether
>>>> the PQfn should have responsibility for endian translation of
integer, it should set PQArgBlock.isint = 0 and
> PQArgBlock.len = 8 and set data pass-by-reference. Endianness should
> be taken care by the PQfn caller. Also we do not modify fe-misc.c
> because there's no point to add pqPutint64/pqGetint64(they are called
> from pqFunctionCall i
ss-by-reference. Endianness should
be taken care by the PQfn caller. Also we do not modify fe-misc.c
because there's no point to add pqPutint64/pqGetint64(they are called
from pqFunctionCall in the patch).
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Ja
> Right. If we had to change anything on the backend side, it would mean
> we had a wire protocol change, which is even less acceptable than a
> libpq ABI change.
The patch does not touch pg_getmsgint64() and I don't think we are not
going have a wire protocol change.
--
Tatsuo
> 2012/9/21 Tatsuo Ishii :
>>>>>> I thought pgPutInt64() takes care of endianness. No?
>>>>>>
>>>>> It works inside of the PGfn(), when isint = 1 towards pointer data type.
>>>>> In my sense, it is a bit problem specific
ranslation
> prior and next to PQfn() invocation; to avoid the int64 specific case-handling
> inside of PQfn() that can be called by other applications.
>
> Am I missing something?
So what do you want to do with pq_getmsgint64()? It exactly does the
same thing as pqPutInt64(), just in
ata type.
> In my sense, it is a bit problem specific solution.
>
> So, I'd like to see other person's opinion here.
I think we cannot change this because we want to keep the counter part
backend side function pq_getmsgint64() as it is (the function is not
part of the patch).
--
Ta
does not
>> have stdint.h. If so, we need to take care of such platforms anyway.
>>
> OK, it makes me clear. It might be helpful a source code comment
> to remain why we used self defined datatype here.
Ok.
> 2012/9/21 Tom Lane :
>> Tatsuo Ishii writes:
>>> To p
n about context of this discussion.
>
> Does it make matter if we include and use int64_t instead
> of the self defined data type?
I think Tom's point is, there are tons of applications which define
their own "int64_t" (at least in 2005).
Also pg_config.h has:
#define HAVE_
xamples/testlo64.c added for 64-bit API example(Yugo Nagata)
Comments and suggestions are welcome.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
lobj64.patch.gz
Description: Binary data
--
Sent via pgsql-hackers mailing lis
> Tatsuo Ishii writes:
>> I am thinking about to implement "multi-master" option for pgbench.
>
> Please consider using Tsung, which solves that problem and many others.
>
> http://tsung.erlang-projects.org/
Thank you for introducing Tsung. I have some question
f confusion between the loid and pageno
> columns (loid already being oid). I'd just as soon not go there,
> at least not till we start seeing actual field complaints about
> 4TB being paltry ;-)
Agreed. 4TB should be enough.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sra
)
= (2^32-1) * (8192/4)
= 8TB
I just want to confirm my calculation is correct.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers
;> 32-bit backend functions.
>
> I don't particularly see a need for loread64 or lowrite64. Who's going
> to be reading or writing more than 2GB at once? If someone tries,
> they'd be well advised to reconsider their code design anyway.
Ok, loread64 and lowrite64 wil
> Tatsuo Ishii writes:
>> I found following in fe-lobj.c:
>
>> * currently, only L_SET is a legal value for whence
>
>> I don't know where "L_SET" comes from.
>
> Hmm, seems to be that way in the original commit to our CVS (Postgres95).
> I
CUR or SEEK_END.
If there's no objection, I will change this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
API as
long as requested read/write data length is smaller than 2GB. So I
think we can safely allow them to access over 2GB lobjs.
lo_lseek: again as long as requested offset is smaller than 2GB, there
would be no problem.
lo_tell:if current seek position is beyond 2GB, returns an error.
Comments,
>> On Tue, Aug 21, 2012 at 7:49 AM, Tatsuo Ishii wrote:
>>> Please let me know if this is not the right place to ask this kind of
>>> queston.
>>>
>>> PostgreSQL Developers FAQ in Japanese:
>>>
>>> http://wiki.postgresql.org/wiki/Develop
> On Wed, Aug 22, 2012 at 9:32 PM, Tatsuo Ishii wrote:
>> Hi,
>>
>> I found following item in the Developer FAQ.
>> I don't see why this is related to developers.
>>
>>
See the archives for an idea what characteristics an alternate compression tool
would need to have in order to be considered for use in core PostgreSQL.
--------
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraos
> On Wed, 2012-08-22 at 01:14 -0400, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > On Wed, 2012-08-22 at 07:27 +0900, Tatsuo Ishii wrote:
>> >> I found this in the TODO list:
>> >> Add API for 64-bit large object access
>> >> If this is a
#x27;s largeobject
> code that would need to be widened, but that's the easiest part of the
> job.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
eans, the comparison is something
> like apple-to-orange. With enhanced pgbench we could do apple-to-apple
> comparison.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hack
to implement such a tool because there's
always a chance to try to retrieve non existing data from hot-standby
because of replication delay.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers m
mplete until they have happened on all nodes, even in the
> asynchronous case.
IMO, that kind of functionnality is beyond the scope of benchmark tools.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-h
tgreSQL streaming replication configuration cannot be a
multi-master configuration and will not be a target of the new
pgbench.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hacke
d could easily reveal bottle
neck of pgbench. However this type of transaction is pretty extrem one
and very different from transactions in the real world. So even if
your argument is true, I guess it's only adopted to "pgbench -S" case.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: htt
Hi,
I found this in the TODO list:
Add API for 64-bit large object access
If this is a still valid TODO item and nobody is working on this, I
would like to work in this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
somehow test propagation of the writes? Such a thing
> would be quite useful, but it seems at first glance like a large
> project.
What does "propagation of the writes" mean?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.
e of many
> mistakes.
Agreed.
> However, here are some ideas you might use:
> 1) pgbench -h host1:port1,host2:port2 ...
> 2) pgbench -h host1,host2 -p port1:port2
Looks good.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraos
f this functionality is to test some cluster software which
have a capability to create multi-master configuration.
Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hacker
?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On Tue, Aug 21, 2012 at 7:49 AM, Tatsuo Ishii wrote:
>> Please let me know if this is not the right place to ask this kind of
>> queston.
>>
>> PostgreSQL Developers FAQ in Japanese:
>>
>> http://wiki.postgresql.org/wiki/Developer_FAQ/ja
>>
>&
7;::boolean::text;
>> text
>> ---
>> false
>> (1 row)
>>
>> That has always seemed quite odd (and occasionally inconvenient) to
>> me.
>
> I think that may be from the cast. I didn't see any transformation in psql.
> Looked like i
PostgreSQL's
repository is CVS, not git. Does anybody know who is the mainter for
this? If there's no particular maintainer for this, I would like to
volunteer to update the page.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sr
e.
If you like xeamcs's spec, I think you'd better add new encoding,
rather than break data compatibility.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
>>>> Tatsuo Ishii writes:
>>>>>> So far as I can see, the only LCPRVn marker code that is actually in
>>>>>> use right now is 0x9d --- there are no instances of 9a, 9b, or 9c
>>>>>> that I can find.
>>>>>&
>>> Tatsuo Ishii writes:
>>>>> So far as I can see, the only LCPRVn marker code that is actually in
>>>>> use right now is 0x9d --- there are no instances of 9a, 9b, or 9c
>>>>> that I can find.
>>>>>
>>>>> I
>> Tatsuo Ishii writes:
>>>> So far as I can see, the only LCPRVn marker code that is actually in
>>>> use right now is 0x9d --- there are no instances of 9a, 9b, or 9c
>>>> that I can find.
>>>>
>>>> I also read in the xemacs in
> Tatsuo Ishii writes:
>>> So far as I can see, the only LCPRVn marker code that is actually in
>>> use right now is 0x9d --- there are no instances of 9a, 9b, or 9c
>>> that I can find.
>>>
>>> I also read in the xemacs internals doc, at
&
eck my work, but I think it's
> right.
For me your commit looks good.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
> So far as I can see, the only LCPRVn marker code that is actually in
> use right now is 0x9d --- there are no instances of 9a, 9b, or 9c
> that I can find.
>
> I also read in the xemacs internals doc, at
> http://www.xemacs.org/Documentation/21.5/html/internals_26.html#SEC145
> that XEmacs think
> I have added comments about mule internal encoding by refreshing my
> memory and from old document found on
> web(http://mibai.tec.u-ryukyu.ac.jp/cgi-bin/info2www?%28mule%29Buffer%20and%20string).
Any objection to apply my patch?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Engl
LCPRV2 case:
If the second byte of wchar (out of 4 bytes of wchar. The first byte
is always 0x00) is in range of 0xf0 to 0xf4, then the first byte of
multibyte must be 0x9c. If the second byte of wchar is in range of
0xf5 to 0xfe, then the first byte of multibyte must be 0x9d.
--
Tatsuo
it's not too clear to me.
Yes, that's because we only support EUC_TW and BIG5 which are using
IS_LCPRV2 in the mule interal encoding, as stated in the comment.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pg
> On Wed, Jun 20, 2012 at 4:04 AM, Tatsuo Ishii wrote:
>> Currently pgbench -i prints following message every 10k tuples created.
>>
>> fprintf(stderr, "%d tuples done.\n", j);
>>
>> I think it's long time ago when the
essage seems to be too often for me. Can we change the frequency
from 10k to 100k? Or should we make the frequency be adjustable from a
command line? Or even better, the frequency should be changed
automatically according to scale factor?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://w
> On Thu, May 31, 2012 at 10:45 AM, Tatsuo Ishii wrote:
>> Just for record, I rerun the test again with my single-LOCK patch, and
>> now total runtime of pg_dump is 113 minutes.
>> 188 minutes(9.0)->125 minutes(git master)->113 minutes(with my patch).
>>
&g
est again with my single-LOCK patch, and
now total runtime of pg_dump is 113 minutes.
188 minutes(9.0)->125 minutes(git master)->113 minutes(with my patch).
So far, I'm glad to see 40% time savings at this point.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
time in pg_dump is spent for SELECTs
against system catalogs. The fix will be turn many SELECTs into single
SELECT, probably using big IN clause for tables oids.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsq
k 13 minutes in total, now
> it only takes 3 seconds. Comments?
Shall I commit to master and all supported branches?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
> hm, it works for me. You might need to do "make clean all" in
> src/bin/pg_dump?
Sorry for noise. It worked. Thanks!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing lis
I have seen this with git master head:
$ pg_dump test
:
:
:
COPY insert_lock (reloid) FROM stdin;
pg_dump: [archiver] internal error -- WriteData cannot be called outside the
context of a DataDumper routine
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
> On Tue, May 22, 2012 at 3:27 PM, Tatsuo Ishii wrote:
>
>> > Thanks for your comments. They clarify a lot.
>> > But I still don't realize how can we distinguish IS_LCPRV2 and IS_LC2?
>> > Isn't it possible for them to produce same pg_wchar?
>>
&g
everity is cleary stated in the
document and you cannot arbitality change it without major version
change anyway. There's nothing different thing here from any other
features what PostgreSQL explicitly provides.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_e
anging existing "S" field not to be localized would work but
I'm afraid it breaks backward compatibility.
Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hacker
s
totally different effect to frontend: aborting transactions or
sessions.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Thanks for your comments. They clarify a lot.
> But I still don't realize how can we distinguish IS_LCPRV2 and IS_LC2?
> Isn't it possible for them to produce same pg_wchar?
If LB is in 0x90 - 0x99 range, then they are LC2.
If LB is in 0xf0 - 0xff range, then they are LCPR
Hi Alexander,
It was good seeing you in Ottawa!
> Hello, Ishii-san!
>
> We've talked on PGCon that I've questions about mule to wchar
> conversion. My questions about pg_mule2wchar_with_len function are
> following. In these parts of code:
> *
> *
> else if (IS_LCPRV1(*from) && len >= 3)
> {
>
t to migrate from existig applications.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ODE" and then
> there would be room to align this switch's explanation with the ones
> above it. I'm tempted to also say that the explanation should be
> MODE can be \"smart\", \"fast\", or \"immediate\"
Thanks for the suggestion. I modified
pg_ctl.c's help
message lacks some long options which are actually in the source code:
'--timeout' and '--mode'. Included is the proposed patch to fix the
problem. If there's no objection, I would like to commit it. Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English
L_CTX_new(TLSv1_method());
be-secure.c:SSL_context = SSL_CTX_new(SSLv23_method());
In my understanding by using SSLV23_method, it is compatible with
SSLv2, SSLv3, and TLSv1 protocol. So it seems there's no particular
reason to use TLSv1_method(). Am I missing something?
--
Tatsuo Ishii
SRA OSS,
ed. However, pqsecure_read() does not retry
when SSL_ERROR_WANT_READ. It seems they are not consistent. Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
SELECT uses temporary tables, then the query result should not
be cached.
- If a SELECT uses unlogged tables, then the query result should not
be cached because their data could vanish after crash recovery. Of
course this is only applied if you plan to use cache storage which
does not survive
actually a bit better than expected. Probably this query was not done
> from a standing start, and so some of the level-1 pages were already in
> buffer cache.
Thanks for the explanation. Now I understand that PostgreSQL works as
expected.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://
ed 3
page accesses (to traverse b tree index tree) before reaching the leaf
page in average. Am I correct or the number is execessive?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsq
> --text-search-config option is missing in document too. Also pg_ctl's
> long name options, such as --silent, are missing in document.
Thanks for the info. I will add them as well unless someone beats me.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.p
. If there's no
objection, I will add it to the manual.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ends or the
transaction ends so I don't think I can use them for my particular
purpose.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Are you suggesting log_statement? I don't think it's a solution by
following reasons:
1) it's slow to enable that on busy systems
2) tables affected by cascading delete/update/drop is not logged in
PostgreSQL log
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.
g_stat_all_tables view and records the last update datetime for each
table (unfortunately the view does not have last modification date).
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgs
oking into pg_depend. I would like to know if
there's any better/convenient way to know it.
For TRIGGER, I cannot thinking of any way. Any idea will be welcome.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgs
f some kind.
Maybe kernel cache effect?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.962510 +4.5%
> 80 group-commit-2012-01-21 12907.062908 +2.8%
Interesting. Comparing with this:
http://archives.postgresql.org/pgsql-hackers/2012-01/msg00804.php
you achieved very small enhancement. Do you think of any reason which
makes the difference?
--
Tatsuo Ishii
SRA OSS, Inc
OT:
Please use mail address "manabu@gmail.com", not
"manabu@gmailc.com" when following this thread. I accidently made
a mistake when I posted the first mail in this thread.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: htt
> On 28.12.2011 14:03, Tatsuo Ishii wrote:
>>>> With help from IBM Japan Ltd. we did some tests on a larger IBM
>>>> machine than Tom Lane has used for his
>>>> test(http://archives.postgresql.org/message-id/8292.1314641...@sss.pgh.pa.us).
>>>> In
bench -c 32 -j 16 -S -T 300 tps = 267726.082168 (including ...
pgbench -c 64 -j 32 -S -T 300 tps = 322582.271713 (including ...
pgbench -c 128 -j 64 -S -T 300 tps = 273071.683663 (including ...
(Graph is attached)
Test environment:
Power 750 (32 physical cores, virtually 128 cores using SMT4)
mem: 256GB
OS: R
ding connections establishing)
> [extended] tps = 205609.438247 (including connections establishing)
> [prepared] tps = 338150.881389 (including connections establishing)
Quite impressive result.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://ww
ed case.
The actual test was performed by one of our engineers in my company
(Toshihiro Kitagawa). I think the answer to your question is yes, but
let me talk to him to make it sure.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ding ...
pgbench -c 64 -j 32 -S -T 300 bench tps = 235709.272642 (including ...
pgbench -c 128 -j 64 -S -T 300 benchtps = 220135.729663 (including ...
Since each core usage is around 50% in the benchmark, there is room for
further performance improvement by eliminating other contentions,
we don't want
to output UTF-8 with BOM, we should not accept UTF-8 with BOM. It
seems we don't have much choice...
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
as "BOM" in COPY, rather we should
regard U+FEFF as "ZERO WIDTH NO-BREAK SPACE".
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
t harder than generating
>> recovery.conf, I think.
>
> Oh? Clearly I've been abusing pgPool2 then. Where's the code that
> generates that?
pgpool-II itself does not generate the file but scripts for pgpool-II
are generating the file as stated in documentation com
Josh,
>> There are many. Tools I can name include pgpool, 2warm, PITRtools, but
>> there are also various tools from Sun, an IBM reseller I have
>> forgotten the name of, OmniTI and various other backup software
>> providers. Those are just the ones I can recall quickly. We've
>> encouraged people
> Tatsuo Ishii writes:
>> While I took a look at MySQL manual (mainly for checking query cache
>> functionality), I noticed that MySQL has following syntx:
>
>> show like 'foo%';
>
>> I think this is usefull for "show pool_status" comma
ke will be something like:
show pool_status like 'client_idle%' will only show the status of
client_idle_limit and client_idle_limit_in_recovery.
Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent
on is whether we need it for any other
> architectures.
Ok. Let me talk to IBM guys...
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Hi,
I am interested in this thread because I may be able to borrow a big
IBM machine and might be able to do some tests on it if it somewhat
contributes enhancing PostgreSQL. Is there anything I can do for this?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
x27;s hard for pgpool-II since there's no API in PostgreSQL for
that. Maybe I will look into the system catalog to find out
children. I'm not sure if I can deal with CASCADE by the same method
though.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:
DROP TABLE CASCADE. Any idea?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to expand "*" to real column lists and so on).
Just F.Y.I.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ave two numbers that are very close to each other. I think this is
> just useless complication, because "amount" is almost always going to
> be 8kB or less.
Oops. My bad. I should have divide "amount" by 1024. Now I understand
your point.
--
Tatsuo Ishii
SRA OSS, In
temp_file_limit)));
}
}
I also attached the whole patch against fd.c at the point when Mark
proposed the changes.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss
M resourcetemp1 ORDER BY 1) AS a;
ERROR: aborting due to exceeding temp file limit, current usage 576kB,
requested size 8192kB, thus it will exceed temp file limit 578kB
Here temp_file_limit is not specified by 8kB unit, so "current usage"
becomes 576kB, which is 8kB unit. I don'
Maybe we could add more info regarding current usage and requested
amount in addition to the temp file limit value. I mean something
like:
ERROR: aborting due to exceeding temp file limit. Current usage 9000kB,
requested size 1024kB, thus it will exceed temp file limit 1kB.
What do you think?
--
a little bit easier.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
501 - 600 of 1697 matches
Mail list logo
