On Mon, Oct 10, 2022 at 08:34:33PM -0700, Nathan Bossart wrote:
> On Mon, Oct 10, 2022 at 02:20:37PM -0400, Bruce Momjian wrote:
> > On Fri, Oct 7, 2022 at 03:23:27PM -0700, Zhihong Yu wrote:
> >> I wonder if SAVEPOINT / subtransaction performance has been boosted since
>
On Mon, Oct 10, 2022 at 02:20:37PM -0400, Bruce Momjian wrote:
> On Fri, Oct 7, 2022 at 03:23:27PM -0700, Zhihong Yu wrote:
>> I wonder if SAVEPOINT / subtransaction performance has been boosted since the
>> blog was written.
>
> No, I have not seen any changes in this ar
On Fri, Oct 7, 2022 at 03:23:27PM -0700, Zhihong Yu wrote:
> Hi,
> I stumbled over:
>
> https://about.gitlab.com/blog/2021/09/29/
> why-we-spent-the-last-month-eliminating-postgresql-subtransactions/
>
> I wonder if SAVEPOINT / subtransaction performance has been boosted
Hi,
I stumbled over:
https://about.gitlab.com/blog/2021/09/29/why-we-spent-the-last-month-eliminating-postgresql-subtransactions/
I wonder if SAVEPOINT / subtransaction performance has been boosted since
the blog was written.
Cheers
Hi,
On 2021-04-05 21:35:21 -0700, Andres Freund wrote:
> See the attached fix. I did include a test that verifies that the
> kill_prior_tuples optimization actually prevents the index from growing,
> when subtransactions are involved. I think it should be stable, even
> with concurrent activity. B
On 2021-04-06 01:34:02 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2021-04-06 00:47:13 -0400, Tom Lane wrote:
> >> Not wanting to distract from your point about xactCompletionCount,
> >> but ... I wonder if we could get away with defining "isObjectPinned"
> >> as "is the OID <= " (an
Andres Freund writes:
> On 2021-04-06 00:47:13 -0400, Tom Lane wrote:
>> Not wanting to distract from your point about xactCompletionCount,
>> but ... I wonder if we could get away with defining "isObjectPinned"
>> as "is the OID <= " (and, in consequence, dropping explicit pin
>> entries from
Hi,
On 2021-04-06 00:47:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The time in 14 is spent mostly below:
> > - 94.58% 0.01% postgres postgres[.] CreateFunction
> >- 94.57% CreateFunction
> > - 94.49% ProcedureCreate
> > - 90.95% record_object_addr
Andres Freund writes:
> The time in 14 is spent mostly below:
> - 94.58% 0.01% postgres postgres[.] CreateFunction
>- 94.57% CreateFunction
> - 94.49% ProcedureCreate
> - 90.95% record_object_address_dependencies
> - 90.93% recordMultipleDependenc
Hi,
In a recent thread ([1]) I found a performance regression of the
following statement
DO $do$
BEGIN FOR i IN 1 .. 1 LOOP
BEGIN
EXECUTE $cf$CREATE OR REPLACE FUNCTION foo() RETURNS VOID LANGUAGE
plpgsql AS $f$BEGIN frakbar; END;$f$;$cf$;
EXCEPTION WHEN others
10 matches
Mail list logo
