Re: Planner performance extremely affected by an hanging transaction (20-30 times)?

From: didier <did447(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Jesper Krogh <jesper(at)krogh(dot)cc>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Bartłomiej Romański <br(at)sentia(dot)pl>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
Date: 2013-09-25 04:49:25
Message-ID: CAJRYxuLTneRZdWwTd3eKEMiSSnBoUOsj37oquCowS5KO3oBQyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi

On Wed, Sep 25, 2013 at 1:30 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> On Tue, Sep 24, 2013 at 11:03 AM, didier <did447(at)gmail(dot)com> wrote:
>
>>
>> As a matter of fact you get the same slow down after a rollback until
>> autovacuum, and if autovacuum can't keep up...
>>
>
> Have you experimentally verified the last part? btree indices have some
> special kill-tuple code which should remove aborted tuples from the index
> the first time they are encountered, without need for a vacuum.
>
> Cheers,
>
> Jeff
>

>
>

Yes my bad, it works but there's leftover junk and a vacuum is still
needed

Running above test with autovacuum off, 1 client and insert 50 000 on
postgresql 9.4 qit version.
Before insert 2 000 queries/s
after insert 80/s
after rollback 800/s (back to 2 000/s if commit)
after vacuum 2 000 /s again and vacuum output:

INFO: vacuuming
"public.categories"

INFO: scanned index "categories_pkey" to remove 50000 row
versions

DETAIL: CPU 0.00s/0.00u sec elapsed 0.01
sec.

INFO: "categories": removed 50000 row versions in 319
pages

DETAIL: CPU 0.00s/0.00u sec elapsed 0.00
sec.

INFO: index "categories_pkey" now contains 1000 row versions in 278
pages

DETAIL: 50000 index row versions were
removed.

272 index pages have been deleted, 136 are currently
reusable.

CPU 0.00s/0.00u sec elapsed 0.00
sec.

INFO: "categories": found 50000 removable, 1000 nonremovable row versions
in 325 out of 325 pages
DETAIL: 0 dead row versions cannot be removed
yet.

There were 0 unused item
pointers.

0 pages are entirely
empty.

CPU 0.00s/0.01u sec elapsed 0.02
sec.

INFO: "categories": stopping truncate due to conflicting lock
request

INFO: vacuuming
"pg_toast.pg_toast_16783"

INFO: index "pg_toast_16783_index" now contains 0 row versions in 1
pages

DETAIL: 0 index row versions were
removed.

0 index pages have been deleted, 0 are currently
reusable.

CPU 0.00s/0.00u sec elapsed 0.00
sec.

INFO: "pg_toast_16783": found 0 removable, 0 nonremovable row versions in
0 out of 0 pages
DETAIL: 0 dead row versions cannot be removed
yet.

There were 0 unused item
pointers.

0 pages are entirely
empty.

CPU 0.00s/0.00u sec elapsed 0.00
sec.

INFO: analyzing
"public.categories"

INFO: "categories": scanned 325 of 325 pages, containing 1000 live rows
and 0 dead rows; 1000 rows in sample, 1000 estimated total rows

perf output after rollback but before vacuum
93.36% postgres
/var/lib/vz/root/165/usr/local/pgsql/bin/postgres
|
|--41.51%-- _bt_checkkeys
| |
| |--93.03%-- _bt_readpage
| | |
| | |--97.46%-- _bt_steppage
| | | _bt_first
| | | btgettuple
| | | FunctionCall2Coll
| | | index_getnext_tid

Didier

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2013-09-25 06:38:03 Re: Performance bug in prepared statement binding in 9.2?
Previous Message Bartłomiej Romański 2013-09-24 23:43:54 Re: Planner performance extremely affected by an hanging transaction (20-30 times)?