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).
>
>
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).
During the testing of bunch of queries with different set of
configura
31 matches
Mail list logo
