On Wed, Apr 10, 2019 at 3:32 PM Amit Kapila wrote:
> On Mon, Apr 8, 2019 at 8:51 AM Amit Kapila
> wrote:
> >
> > On Mon, Apr 8, 2019 at 7:54 AM Jamison, Kirk
> wrote:
> > > So I am marking this thread as “Ready for Committer”.
> > >
> >
> > Thanks, Hari and Jamison for verification. The patche
On Mon, Apr 8, 2019 at 8:51 AM Amit Kapila wrote:
>
> On Mon, Apr 8, 2019 at 7:54 AM Jamison, Kirk wrote:
> > So I am marking this thread as “Ready for Committer”.
> >
>
> Thanks, Hari and Jamison for verification. The patches for
> back-branches looks good to me. I will once again verify them
On Mon, Apr 8, 2019 at 7:54 AM Jamison, Kirk wrote:
>
> On Monday, April 8, 2019 9:04 AM (GMT+9), Haribabu Kommi wrote:
>
> >On Thu, Apr 4, 2019 at 3:29 PM Amit Kapila wrote:
>
> > The patch looks good to me. I have changed the commit message and ran
> > the pgindent in the attached patch. Can
On Monday, April 8, 2019 9:04 AM (GMT+9), Haribabu Kommi wrote:
>On Thu, Apr 4, 2019 at 3:29 PM Amit Kapila
>mailto:amit.kapil...@gmail.com>> wrote:
>On Wed, Apr 3, 2019 at 10:45 AM Haribabu Kommi
>mailto:kommi.harib...@gmail.com>> wrote:
>>
>> Thanks for the review.
>>
>> While changing the app
On Thu, Apr 4, 2019 at 3:29 PM Amit Kapila wrote:
> On Wed, Apr 3, 2019 at 10:45 AM Haribabu Kommi
> wrote:
> >
> > Thanks for the review.
> >
> > While changing the approach to use the is_parallel_worker_flag, I thought
> > that the rest of the stats are also not required to be updated and also
On Wed, Apr 3, 2019 at 10:45 AM Haribabu Kommi wrote:
>
> Thanks for the review.
>
> While changing the approach to use the is_parallel_worker_flag, I thought
> that the rest of the stats are also not required to be updated and also those
> are any way write operations and those values are zero an
On Wed, Apr 3, 2019 at 1:59 PM Amit Kapila wrote:
> On Thu, Mar 28, 2019 at 11:43 AM Haribabu Kommi
> wrote:
> >
> > On Wed, Mar 27, 2019 at 11:27 PM Amit Kapila
> wrote:
> >>
> >> On Wed, Mar 27, 2019 at 6:53 AM Haribabu Kommi <
> kommi.harib...@gmail.com> wrote:
> >> > On Tue, Mar 26, 2019 at
On Thu, Mar 28, 2019 at 11:43 AM Haribabu Kommi
wrote:
>
> On Wed, Mar 27, 2019 at 11:27 PM Amit Kapila wrote:
>>
>> On Wed, Mar 27, 2019 at 6:53 AM Haribabu Kommi
>> wrote:
>> > On Tue, Mar 26, 2019 at 9:08 PM Amit Kapila
>> > wrote:
>> >>
>> >> As part of this thread, maybe we can
>> >> j
On Thursday, March 28, 2019 3:13 PM (GMT+9), Haribabu Kommi wrote:
> I tried the approach as your suggested as by not counting the actual parallel
> work
> transactions by just releasing the resources without touching the counters,
> the counts are not reduced much.
>
> HEAD - With 4 parallel work
On Wed, Mar 27, 2019 at 11:27 PM Amit Kapila
wrote:
> On Wed, Mar 27, 2019 at 6:53 AM Haribabu Kommi
> wrote:
> > On Tue, Mar 26, 2019 at 9:08 PM Amit Kapila
> wrote:
> >>
> >> As part of this thread, maybe we can
> >> just fix the case of the parallel cooperating transaction.
> >
> >
> > Wit
On Wed, Mar 27, 2019 at 6:53 AM Haribabu Kommi wrote:
> On Tue, Mar 26, 2019 at 9:08 PM Amit Kapila wrote:
>>
>> As part of this thread, maybe we can
>> just fix the case of the parallel cooperating transaction.
>
>
> With the current patch, all the parallel implementation transaction are
> ge
On Tue, Mar 26, 2019 at 9:08 PM Amit Kapila wrote:
> On Mon, Mar 25, 2019 at 6:55 PM Haribabu Kommi
> wrote:
> >
> >
> > Thanks to everyone for their opinions and suggestions to improve.
> >
> > Without parallel workers, there aren't many internal implementation
> > logic code that causes the st
On Mon, Mar 25, 2019 at 6:55 PM Haribabu Kommi wrote:
>
> On Sat, Mar 23, 2019 at 11:10 PM Amit Kapila wrote:
>>
>> On Sat, Mar 23, 2019 at 9:50 AM Alvaro Herrera
>> wrote:
>> >
>> > On 2019-Mar-23, Amit Kapila wrote:
>> >
>> > > I think some users might also be interested in the write transact
On Sat, Mar 23, 2019 at 11:10 PM Amit Kapila
wrote:
> On Sat, Mar 23, 2019 at 9:50 AM Alvaro Herrera
> wrote:
> >
> > On 2019-Mar-23, Amit Kapila wrote:
> >
> > > I think some users might also be interested in the write transactions
> > > happened in the system, basically, those have consumed xi
On Sat, Mar 23, 2019 at 9:50 AM Alvaro Herrera wrote:
>
> On 2019-Mar-23, Amit Kapila wrote:
>
> > I think some users might also be interested in the write transactions
> > happened in the system, basically, those have consumed xid.
>
> Well, do they really want to *count* these transactions, or i
On 2019-Mar-23, Amit Kapila wrote:
> On Fri, Mar 22, 2019 at 10:04 AM Alvaro Herrera
> wrote:
> > Not count them if they're implementation details; otherwise count them.
> > For example, IMO autovacuum transactions should definitely be counted
> > (as one transaction, even if they run parallel v
On Fri, Mar 22, 2019 at 10:04 AM Alvaro Herrera
wrote:
> On 2019-Mar-21, Robert Haas wrote:
>
> > I agree that it's a little funny to count the parallel worker commit
> > as a separate transaction, since in a certain sense it is part of the
> > same transaction.
>
> Right. So you don't count it.
On Fri, Mar 22, 2019 at 12:34 AM Alvaro Herrera
wrote:
> > And then you have to decide what to do about other background
> > transactions.
>
> Not count them if they're implementation details; otherwise count them.
> For example, IMO autovacuum transactions should definitely be counted
> (as one t
On 2019-Mar-21, Robert Haas wrote:
> I don't have a strong position on what the "right" thing
> to do here is, but I think if you want to know how many client
> transactions are being executed, you should count them on the client
> side, as pgbench does.
I think counting on the client side is unt
On Thu, Mar 21, 2019 at 2:18 AM Haribabu Kommi wrote:
> With Inclusion of parallel worker transactions, the TPS will be a higher
> number,
> thus user may find it as better throughput. This is the case with one of our
> tool.
> The tool changes the configuration randomly to find out the best con
On Wed, Mar 20, 2019 at 7:38 PM Amit Kapila wrote:
> On Sun, Feb 10, 2019 at 10:54 AM Haribabu Kommi
> wrote:
> > On Sat, Feb 9, 2019 at 4:07 PM Amit Kapila
> wrote:
> >>
> >> I don't think so. It seems to me that we should consider it as a
> >> single transaction. Do you want to do the leg w
On Sun, Feb 10, 2019 at 10:54 AM Haribabu Kommi
wrote:
> On Sat, Feb 9, 2019 at 4:07 PM Amit Kapila wrote:
>>
>> I don't think so. It seems to me that we should consider it as a
>> single transaction. Do you want to do the leg work for this and try
>> to come up with a patch? On a quick look,
Hi Haribabu,
The latest patch fails while applying header files part. Kindly rebase.
The patch looks good to me. However, I wonder what are the other scenarios
where xact_commit is incremented because even if I commit a single
transaction with your patch applied the increment in xact_commit is >
I tried to confirm the patch with the following configuration:
max_parallel_workers_per_gather = 2
autovacuum = off
postgres=# BEGIN;
BEGIN
postgres=# select xact_commit from pg_stat_database where datname = 'postgres';
xact_commit
-
118
(1 row)
postgres=# explain analyz
On Tue, Mar 19, 2019 at 6:47 PM Jamison, Kirk
wrote:
> Hi Hari-san,
>
>
>
> On Sunday, February 10, 2019 2:25 PM (GMT+9), Haribabu Kommi wrote:
>
> > I try to fix it by adding a check for parallel worker or not and based
> on it
>
> > count them into stats. Patch attached.
>
> >
>
> > With this p
On Tue, Mar 19, 2019 at 2:32 PM Rahila Syed
wrote:
> Hi Haribabu,
>
> The latest patch fails while applying header files part. Kindly rebase.
>
Thanks for the review.
> The patch looks good to me. However, I wonder what are the other scenarios
> where xact_commit is incremented because even if
Hi Hari-san,
On Sunday, February 10, 2019 2:25 PM (GMT+9), Haribabu Kommi wrote:
> I try to fix it by adding a check for parallel worker or not and based on it
> count them into stats. Patch attached.
>
> With this patch, currently it doesn't count parallel worker transactions, and
> rest of the s
On Sat, Feb 9, 2019 at 4:07 PM Amit Kapila wrote:
> On Fri, Feb 8, 2019 at 6:55 AM Haribabu Kommi
> wrote:
> >
> > On Thu, Feb 7, 2019 at 9:31 PM Haribabu Kommi
> wrote:
> >>
> >>
> >> This is because of larger xact_commit value than default configuration.
> With the changed server configuratio
On Fri, Feb 8, 2019 at 6:55 AM Haribabu Kommi wrote:
>
> On Thu, Feb 7, 2019 at 9:31 PM Haribabu Kommi
> wrote:
>>
>>
>> This is because of larger xact_commit value than default configuration. With
>> the changed server configuration, that leads to generate more parallel
>> workers and every p
On Thu, Feb 7, 2019 at 9:31 PM Haribabu Kommi
wrote:
> Hi Hackers,
>
> Does increase in Transaction commits per second means good query
> performance?
> Why I asked this question is, many monitoring tools display that number of
> transactions
> per second in the dashboard (including pgadmin).
>
>
30 matches
Mail list logo
