>From: Tsunakawa, Takayuki
>>From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
>> number of tables | 100 |1000|1
>> ---
>> TPS (master) |10966 |10654 |9099
>> TPS (patch)| 11137 (+1%) |10710 (+0%) |772 (-
Hi Meskes-san,
> Ah right, my bad. The workaround should have been:
Thank you. It works.
> As for the PREPARE statement itself, could you try the attached small
> patch please.
It works well for my statement
"EXEC SQL PREPARE test_prep (int) AS SELECT id from test_table where id = $1;".
Howe
On Wed, Feb 20, 2019 at 11:50:42AM +0100, Oleksii Kliukin wrote:
> RecoverPreparedTransactions calls ProcessRecords with
> twophase_recover_callbacks right after releasing the TwoPhaseStateLock, so I
> think lock_held should be false here (matching the similar call of
> TwoPhaseGetDummyProc at lock
From: Jamison, Kirk [mailto:k.jami...@jp.fujitsu.com]
> 1) tcp_user_timeout parameter
> I think this can be "committed" separately when it's finalized.
Do you mean you've reviewed and tested the patch by simulating a communication
failure in the way Nagaura-san suggested?
> 2) tcp_socket_timeou
Hi,
Jeff Janes raised an issue [1] about PD_ALL_VISIBLE not being set correctly
while loading data via COPY FREEZE and had also posted a draft patch.
I now have what I think is a more complete patch. I took a slightly
different approach and instead of setting PD_ALL_VISIBLE bit initially and
then
On Tue, Jan 15, 2019 at 8:48 PM Darafei "Komяpa" Praliaskouski <
m...@komzpa.net> wrote:
> Hello,
>
> Today I bumped into need to limit first VACUUM time on data import.
> I'm using utility called osmium together with COPY FREEZE to import
> openstreetmap data into database.
>
> osmium export -c o
From: Ideriha, Takeshi/出利葉 健
> I checked it with perf record -avg and perf report.
> The following shows top 20 symbols during benchmark including kernel space.
> The main difference between master (unpatched) and patched one seems that
> patched one consumes cpu catcache-evict-and-refill functions
On Thu, 21 Feb 2019 at 18:02, Thomas Munro wrote:
> David Rowley posted some interesting stuff about an ArrayList[1] that
> would replace List in many places. (I probably would have replied to
> that thread if I hadn't changed email account, sorry.) I had similar
> thoughts when I needed to main
From: Robert Haas [mailto:robertmh...@gmail.com]
> That might be enough to justify having the parameter. But I'm not
> quite sure how high the value would need to be set to actually get the
> benefit in a case like that, or what happens if you set it to a value
> that's not quite high enough.
Hi, Kirk-san.
Thank you for summarizing this thread.
On Tue, Feb 19, 2019 at 6:05 PM, Jamison, Kirk wrote:
> 1) tcp_user_timeout parameter
> As for user_timeout param, there seems to be a common agreement with regards
> to its need.
> I think this can be "committed" separately when it's finalized
On Mon, Feb 11, 2019 at 10:48 PM John Naylor
wrote:
>
> On 2/9/19, Amit Kapila wrote:
> > On Tue, Feb 5, 2019 at 3:25 PM John Naylor
> > wrote:
> >>
> >> On Tue, Feb 5, 2019 at 4:04 AM Amit Kapila
> >> wrote:
> > This is certainly a good test w.r.t code coverage of new code, but I
> > have few
From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com]
> BTW, tcp_user_timeout parameter of servers and clients have same name in
> my current implementation.
> I think it would be better different name rather than same name.
> I'll name them as the following a) or b):
> a) server_tcp_u
On Thu, Feb 21, 2019 at 7:58 AM Amit Kapila wrote:
> So here you are inserting 4-byte integer and 1024-bytes variable
> length record. So the tuple length will be tuple_header (24-bytes) +
> 4-bytes for integer + 4-bytes header for variable length data + 1024
> bytes of actual data. So, the leng
On Thu, Jan 31, 2019 at 04:08:18PM +0900, Michael Paquier wrote:
> End-of-commit-fest rebase and moved to next CF.
Rebased version fixing some conflicts with HEAD.
--
Michael
From 5844b0ba07fdd8373a7ef15a1676178cae53c40d Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Tue, 25 Dec 2018 12:21:
Hi, Tsunakawa-san
Thank you for your comments.
On Wed, Feb 20, 2019 at 5:56 PM, Tsunakawa, Takayuki wrote:
> > Perhaps you could also clarify a bit more through documentation on how
> > socket_timeout handles the timeout differently from statement_timeout
> > and tcp_user_timeout.
> Maybe. Could
On Wed, Feb 20, 2019 at 08:12:55PM -0500, Tom Lane wrote:
> The second para explains the cases in which you actually do need to
> provide "host", but I'm afraid that the first sentence will have
> misled people enough that they won't get the point.
>
> I don't think there's anything very wrong with
From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com]
> > Maybe. Could you suggest good description?
> Clients wait until the socket become readable when they try to get results
> of their query.
> If the socket state get readable, clients read results.
> (See src/interfaces/libpq/fe-exec.c
Hi Ramanarayana,
Thank you for your review and suggestion. Please see the attached updated patch.
> Issues found while testing
>1) If invalid value is given to PGLOGMINLEVEL, empty log file is created which
>should not happen.
Thank you for your test. However in my dev environment, empty log fil
101 - 118 of 118 matches
Mail list logo
