| From: | Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Borodin Vladimir <root(at)simply(dot)name>, Хомик Кирилл <khomikki(at)yandex-team(dot)ru> |
| Subject: | Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range |
| Date: | 2017-05-04 16:12:55 |
| Message-ID: | 16CEC03B-252D-4724-B06E-421F3EA2407A@yandex.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Maybe we need another type of snapshot that would accept any
> non-vacuumable tuple. I really don't want SnapshotAny semantics here,
> but a tuple that was live more recently than the xmin horizon seems
> like it's acceptable enough. HeapTupleSatisfiesVacuum already
> implements the right behavior, but we don't have a Snapshot-style
> interface for it.
I have tried to implement this new type of snapshot that accepts any
non-vacuumable tuples.
We have tried this patch in our load environment. And it has smoothed out
and reduced magnitude of the cpu usage peaks.
But this snapshot does not solve the problem completely.
Patch is attached.
| Attachment | Content-Type | Size |
|---|---|---|
| snapshot_non_vacuumable.patch | application/octet-stream | 3.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2017-05-04 16:18:24 | Re: statement_timeout is not working as expected with postgres_fdw |
| Previous Message | Tom Lane | 2017-05-04 15:36:50 | Re: CTE inlining |