Re: [HACKERS] Clock with Adaptive Replacement

06.05.2018 20:28, Andrey Borodin пишет: > >> 6 мая 2018 г., в 20:38, Yura Sokolov <funny.fal...@gmail.com> написал(а): >> >> I've been playing with logarithmic scale in postgresql roughly year ago. >> I didn't found any benefits compared to current code. In fa

Re: [HACKERS] Clock with Adaptive Replacement

06.05.2018 11:20, Andrey Borodin пишет: > > >> 5 мая 2018 г., в 13:25, Yura Sokolov <funny.fal...@gmail.com> написал(а): >> >> 05.05.2018 09:16, Andrey Borodin пишет: >>> Hi! >>> >>>> 4 мая 2018 г., в 16:05, Юрий Соколов <funny.fa

Re: [HACKERS] Clock with Adaptive Replacement

05.05.2018 09:16, Andrey Borodin пишет: > Hi! > >> 4 мая 2018 г., в 16:05, Юрий Соколов >> написал(а): >> >> I didn't suggest log scale of usages, but rather >> "replacement-period based" increment: usage count could be >> incremented at most once in NBlocks/32 replaced

Re: [HACKERS] Clock with Adaptive Replacement

02.05.2018 01:37, Peter Geoghegan пишет: > On Tue, May 1, 2018 at 11:58 AM, Robert Haas wrote: >> I agree that double-counting correlated accesses is a a problem, and I >> agree that we probably want to do something about it. I am skeptical >> that using wall-clock time is

Re: [HACKERS] Small improvement to compactify_tuples

23.01.2018 06:34, Stephen Frost пишет: > Greetings, > > * Юрий Соколов (funny.fal...@gmail.com) wrote: >> On Wed, Nov 29, 2017 at 8:00 AM, Peter Geoghegan wrote: >>> On Tue, Nov 28, 2017 at 2:41 PM, Andres Freund wrote: Maybe it's a stupid question. But

Re: [HACKERS] Two pass CheckDeadlock in contentent case

11.07.2018 17:01, Ashutosh Bapat пишет: > The patch still applies and it's part of this commitfest. > > On Tue, Oct 3, 2017 at 8:36 PM, Sokolov Yura wrote: >> On 2017-10-03 17:30, Sokolov Yura wrote: >>> >>> Good day, hackers. >>> >>> During hard workload sometimes process reaches deadlock

Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)

08.03.2018 03:42, Tomas Vondra пишет: > On 03/06/2018 06:23 AM, Yura Sokolov wrote: >> 05.03.2018 18:00, Tom Lane пишет: >>> Tomas Vondra <tomas.von...@2ndquadrant.com> writes: >>>> Snapshots are static (we don't really add new XIDs into existing ones, >&

Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)

17.03.2018 03:36, Tomas Vondra пишет: > > On 03/17/2018 12:03 AM, Yura Sokolov wrote: >> 16.03.2018 04:23, Tomas Vondra пишет: >>> >>> ... >>> >>> OK, a few more comments. >>> >>> 1) The code in ExtendXipSizeForHash seem

Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)

23.03.2018 17:59, Amit Kapila пишет: > On Sat, Mar 10, 2018 at 7:41 AM, Yura Sokolov <funny.fal...@gmail.com> wrote: >> 08.03.2018 03:42, Tomas Vondra пишет: >>> One reason against building the hash table in GetSnapshotData is that >>> we'd build it even when the s

Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)

16.03.2018 04:23, Tomas Vondra пишет: > > > On 03/10/2018 03:11 AM, Yura Sokolov wrote: >> 08.03.2018 03:42, Tomas Vondra пишет: >>> On 03/06/2018 06:23 AM, Yura Sokolov wrote: >>>> 05.03.2018 18:00, Tom Lane пишет: >>>>> Tomas Vondra <

Re: [HACKERS] Small improvement to compactify_tuples

01.03.2018 22:22, Andres Freund пишет: > Hi, > > On 2018-02-25 21:39:46 +0300, Yura Sokolov wrote: >>> If that's the case then does it really make sense to make this change..? >> >> I don't think it is really necessary to implement generic version >> throug

Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)

05.03.2018 18:00, Tom Lane пишет: > Tomas Vondra writes: >> Snapshots are static (we don't really add new XIDs into existing ones, >> right?), so why don't we simply sort the XIDs and then use bsearch to >> lookup values? That should fix the linear search, without

Re: [HACKERS] Block level parallel vacuum

Excuse me for being noisy. Increasing vacuum's ring buffer improves vacuum upto 6 times. https://www.postgresql.org/message-id/flat/20170720190405.GM1769%40tamriel.snowman.net This is one-line change. How much improvement parallel vacuum gives? 31.10.2018 3:23, Masahiko Sawada пишет: > On Tue,

Re: Add PortalDrop in exec_execute_message

Alvaro Herrera wrote 2021-06-08 00:07: On 2021-May-27, Yura Sokolov wrote: Alvaro Herrera писал 2021-05-26 23:59: > I don't think they should do that. The portal remains open, and the > libpq interface does that. The portal gets closed at end of transaction > without the nee

Re: Use simplehash.h instead of dynahash in SMgr

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested I believe it is ready for committer. The new status of this

Re: plan with result cache is very slow when work_mem is not enough

David Rowley писал 2021-05-09 04:01: On Sun, 9 May 2021 at 03:29, Pavel Stehule wrote: Personally, I have not problem with too slow assertions, although it is not too practical. The main problem is some shock, and feeling so some is wrong. I spent 1 hour detecting if it is a bug or not.

Re: plan with result cache is very slow when work_mem is not enough

cache hashtable, therefore it reaches quadratic complexity easily (or more correct M*N, where M - size of a table, N - eviction count). regards, Yura Sokolov

Re: plan with result cache is very slow when work_mem is not enough

ou > >run with asserts on large amounts of data, I think this is acceptable. > >I had the same dilemma with the new BRIN index opclasses, which also >have some extensive and expensive assert checks - for the regression >tests that's fine, and it proved very useful during development. > >I have considered enabling those extra checks only on request somehow, >but I'd bet no one would do that and I'd forget it exists pretty soon. > > >regards Perhaps there is need for flag "heavy asserts". Or option "--enable-cassert=heavy". Then USE_ASSERT_CHECKING could be defined to integer 1 or 2 depending on "heaviness" of enabled checks. regards Yura Sokolov

Re: Add PortalDrop in exec_execute_message

Tom Lane писал 2021-05-21 21:23: Yura Sokolov writes: I propose to add PortalDrop at the 'if (completed)' branch of exec_execute_message. This violates our wire protocol specification, which specifically says If successfully created, a named portal object lasts till the end

Re: Clear empty space in a page.

Hi, Andres Freund wrote 2021-05-31 00:07: Hi, On 2021-05-30 03:10:26 +0300, Yura Sokolov wrote: While this result is not directly applied to stock PostgreSQL, I believe page compression is important for full_page_writes with wal_compression enabled. And probably when PostgreSQL is used

Re: Add PortalDrop in exec_execute_message

Alvaro Herrera писал 2021-05-26 23:59: On 2021-May-25, Yura Sokolov wrote: Tom Lane писал 2021-05-21 21:23: > Yura Sokolov writes: > > I propose to add PortalDrop at the 'if (completed)' branch of > > exec_execute_message. > > This violates our wire protocol

Re: Add PortalDrop in exec_execute_message

seek-able? regards, tom lane regards Yura Sokolov

Clear empty space in a page.

idn't measure impact on raw performance yet. regards, Yura Sokolov aka funny_falconcommit 6abfcaeb87fcb396c5e2dccd434ce2511314ff76 Author: Yura Sokolov Date: Sun May 30 02:39:17 2021 +0300 Clear empty space in a page Write zeroes to just cleared space in PageRepair

Re: rand48 replacement

Fabien COELHO писал 2021-07-04 23:29: The important property of determinism is that if I set a seed, and then make an identical set of calls to the random API, the results will be identical every time, so that it's possible to write tests with predictable/repeatable results. Hmmm… I like my

Re: rand48 replacement

Fabien COELHO wrote 2021-07-03 11:45: And a v5 where an unused test file does also compile if we insist. About patch: 1. PostgreSQL source uses `uint64` and `uint32`, but not `uint64_t`/`uint32_t` 2. I don't see why pg_prng_state could not be `typedef uint64 pg_prng_state[2];` 3. Then

Re: Extensible storage manager API - smgr hooks

Anastasia Lubennikova писал 2021-06-30 00:49: Hi, hackers! Many recently discussed features can make use of an extensible storage manager API. Namely, storage level compression and encryption [1], [2], [3], disk quota feature [4], SLRU storage changes [5], and any other features that may want

Re: rand48 replacement

Fabien COELHO писал 2021-07-06 09:13: Hello Yura, I believe most "range" values are small, much smaller than UINT32_MAX. In this case, according to [1] fastest method is Lemire's one (I'd take original version from [2]) [...] Yep. I share your point that the range is more often 32 bits.

Re: rand48 replacement

Fabien COELHO писал 2021-07-06 23:49: Hello Yura, However, I'm not enthousiastic at combining two methods depending on the range, the function looks complex enough without that, so I would suggest not to take this option. Also, the decision process adds to the average cost, which is

Add PortalDrop in exec_execute_message

Hi, hackers. I've been playing with "autoprepared" patch, and have got isolation "freeze-the-dead" test stuck on first VACUUM FREEZE statement. After some research I found issue is reproduced with unmodified master branch if extended protocol used. I've prepared ruby script for demonstration

Re: Use simplehash.h instead of dynahash in SMgr

Andres Freund писал 2021-04-26 21:46: Hi, On 2021-04-25 01:27:24 +0300, Yura Sokolov wrote: It is quite interesting result. Simplehash being open-addressing with linear probing is friendly for cpu cache. I'd recommend to define SH_FILLFACTOR with value lower than default (0.9). I believe 0.75

Re: Use simplehash.h instead of dynahash in SMgr

commit fest. regards, Yura Sokolov. Postgres Proffesional https://www.postgrespro.com PS. David, please send patch once again since my mail client reattached files in previous messages, and commit fest robot could think I'm author.

Re: Use simplehash.h instead of dynahash in SMgr

David Rowley писал 2021-04-29 02:51: On Thu, 29 Apr 2021 at 00:28, Yura Sokolov wrote: The best result is with just: return (uint32)rnode->node.relNode; ie, relNode could be taken without mixing at all. relNode is unique inside single database, and almost unique among whole clus

Re: Use simplehash.h instead of dynahash in SMgr

David Rowley писал 2021-04-25 05:23: Thanks for having a look at this. "On Sun, 25 Apr 2021 at 10:27, Yura Sokolov wrote: It is quite interesting result. Simplehash being open-addressing with linear probing is friendly for cpu cache. I'd recommend to define SH_FILLFACTOR with value

Re: Use simplehash.h instead of dynahash in SMgr

David Rowley писал 2021-04-24 18:58: Hackers, Last year, when working on making compactify_tuples() go faster for 19c60ad69, I did quite a bit of benchmarking of the recovery process. The next thing that was slow after compactify_tuples() was the hash lookups done in smgropen(). Currently, we

Re: Use simplehash.h instead of dynahash in SMgr

David Rowley писал 2021-04-25 16:36: On Sun, 25 Apr 2021 at 18:48, Yura Sokolov wrote: If you read comments in SH_START_ITERATE, you'll see: * Search for the first empty element. As deletions during iterations are * supported, we want to start/end at an element that cannot be affected

Old Postgresql version on i7-1165g7

ies or bug of concrete CPU installed in the notebook. It will be great if some with i7-11* could try to make check and report if it also fails or not. With regards, Yura Sokolov PostgresPro

Re: Old Postgresql version on i7-1165g7

Yura Sokolov писал 2021-04-18 23:29: Tom Lane писал 2021-04-13 17:45: Justin Pryzby writes: On Fri, Apr 09, 2021 at 04:28:25PM +0300, Yura Sokolov wrote: Occasinally I found I'm not able to `make check` old Postgresql versions. I've bisected between REL_11_0 and "Rename pg_rew

Re: Old Postgresql version on i7-1165g7

Tom Lane писал 2021-04-13 17:45: Justin Pryzby writes: On Fri, Apr 09, 2021 at 04:28:25PM +0300, Yura Sokolov wrote: Occasinally I found I'm not able to `make check` old Postgresql versions. I've bisected between REL_11_0 and "Rename pg_rewind's copy_file_range()"

Re: Old Postgresql version on i7-1165g7

Yura Sokolov писал 2021-04-09 16:28: Good day, hackers. I've got HP ProBook 640g8 with i7-1165g7. I've installed Ubuntu 20.04 LTS on it and started to play with PostgreSQL sources. Occasinally I found I'm not able to `make check` old Postgresql versions. At least 9.6 and 10

Re: Bug in huge simplehash

Andres Freund писал 2021-08-13 12:21: Hi, On 2021-08-10 11:52:59 +0300, Yura Sokolov wrote: - sizemask is set only in SH_COMPUTE_PARAMETERS . And it is set in this way: /* now set size */ tb->size = size; if (tb->size == SH_MAX_SIZE) tb->siz

Re: Bug in huge simplehash

Ranier Vilela писал 2021-08-13 14:12: Em sex., 13 de ago. de 2021 às 07:15, Andres Freund escreveu: Hi, On 2021-08-13 12:44:17 +0300, Yura Sokolov wrote: Andres Freund писал 2021-08-13 12:21: Any chance you'd write a test for simplehash with such huge amount of values? It'd require

jff: checksum algorithm is not as intended

x(0x0327ff01) (where mix is a `__tmp` to `checksum` transformation) regards, Yura Sokolov y.soko...@postgrespro.ru funny.fal...@gmail.com PS. Test program in Crystal language is attached and output for current CHECKSUM_COMP implementation and "correct" (intended). Excuse me for Crystal,

Re: [PoC] Improve dead tuple storage for lazy vacuum

esser memory consumption (and therefore better times) on 10x test, when page number exceed 2^23 (8M). It still produce "correct" result for test since every page is filled in the same way. Could you push your fixes for radix, please? regards, Yura Sokolov y.soko...@postgrespro.ru funny.fal...@gmail.com

Bug in huge simplehash

== SH_MAX_SIZE/2` and we call `SH_GROW(tb, tb->size * 2)`, then SH_GROW(tb, 0) is called due to truncation. And SH_COMPUTE_PARAMETERS is also accepts `uint32 newsize`. Ahh... ok, patch is updated to fix this as well. regards. - Yura Sokolov y.soko...@postgrespro.ru funny.fal...@gmail.com

Re: Bug in huge simplehash

Ranier Vilela писал 2021-08-10 14:21: Em ter., 10 de ago. de 2021 às 05:53, Yura Sokolov escreveu: I went to check SH_GROW and It is `SH_GROW(SH_TYPE *tb, uint32 newsize)` :-((( Therefore when `tb->size == SH_MAX_SIZE/2` and we call `SH_GROW(tb, tb->size * 2)`, then SH_GROW

Re: RFC: Improve CPU cache locality of syscache searches

Andres Freund писал 2021-08-06 06:49: Hi, On 2021-08-06 06:43:55 +0300, Yura Sokolov wrote: Why don't use simplehash or something like that? Open-addressing schemes show superior cache locality. I thought about that as well - but it doesn't really resolve the question of what we want

Re: RFC: Improve CPU cache locality of syscache searches

on-empty entry will be matched entry most of time, and memory lookup for key comparison will be amortized free. Note that 8byte entry with fill factor 0.66 consumes amortized 12.12 byte, while 16byte entry with fill factor 0.99 consumes amortized 16.16byte. regards, Yura Sokolov y.soko...@postgrespro.ru funny.fal...@gmail.com

Re: [PoC] Improve dead tuple storage for lazy vacuum

Yura Sokolov писал 2021-07-29 18:29: I've attached IntegerSet2 patch for pgtools repo and benchmark results. Branch https://github.com/funny-falcon/pgtools/tree/integerset2 Strange web-mail client... I never can be sure what it will attach... Reattach benchmark results regards, Yura

Re: [PoC] Improve dead tuple storage for lazy vacuum

In fact, my code uses bump allocator internally to avoid "per-allocation overhead" of "aset", "slab" or "generational". And IntegerSet2 version even uses it for all allocations since it has no reallocatable parts. Well, if datastructure has reallocatable pa

Re: [PoC] Improve dead tuple storage for lazy vacuum

Masahiko Sawada писал 2021-07-29 17:29: On Thu, Jul 29, 2021 at 8:03 PM Yura Sokolov wrote: Masahiko Sawada писал 2021-07-29 12:11: > On Thu, Jul 29, 2021 at 3:53 AM Andres Freund > wrote: >> >> Hi, >> >> On 2021-07-27 13:06:56 +0900, Masahiko Sawada wrot

Re: Double partition lock in bufmgr

В Пт, 18/12/2020 в 15:20 +0300, Konstantin Knizhnik пишет: > Hi hackers, > > I am investigating incident with one of out customers: performance of > the system isdropped dramatically. > Stack traces of all backends can be found here: > http://www.garret.ru/diag_20201217_102056.stacks_59644 >

Re: Speed up transaction completion faster after many relations are accessed in a transaction

I've made some remarks in related thread: https://www.postgresql.org/message-id/flat/0A3221C70F24FB45833433255569204D1FB976EF@G01JPEXMBYT05 The new status of this patch is: Waiting on Author

Re: Use simplehash.h instead of dynahash in SMgr

E->segments` array. I think, second option is more prefered: - `DH_TYPE->segments[x]` inevitable accessed on every operation, therefore why not store some info here? - if nitems/used_items will be in `DH_TYPE->segments[x]`, then hashtable iteration doesn't need bitmap at all - there will b

Avoid dynahash's freelist in BufferAlloc.

.ru funny.fal...@gmail.com From 2afbc5a59c3ccd3fec14105aff40252eeaacf40c Mon Sep 17 00:00:00 2001 From: Yura Sokolov Date: Wed, 22 Sep 2021 13:10:37 +0300 Subject: [PATCH] More gentle dynahash usage in buffer allocation. When BufferAlloc reuses some valid buffer, there is no need to go thro

BufferAlloc: don't take two simultaneous locks

, Yura Sokolov y.soko...@postgrespro.ru funny.fal...@gmail.com From a1606eaa124fc497763ed5e28e22cbc8f6443b33 Mon Sep 17 00:00:00 2001 From: Yura Sokolov Date: Wed, 22 Sep 2021 13:10:37 +0300 Subject: [PATCH v0] bufmgr: do not acquire two partition locks. Acquiring two partition locks leads to complex

Re: BufferAlloc: don't take two simultaneous locks

В Пт, 01/10/2021 в 15:46 -0700, Zhihong Yu wrote: > > > On Fri, Oct 1, 2021 at 3:26 PM Yura Sokolov > wrote: > > Good day. > > > > I found some opportunity in Buffer Manager code in BufferAlloc > > function: > > - When valid buffer is evicted, Buff

Re: XTS cipher mode for cluster file encryption

cle/view/7360 [4] https://github.com/google/adiantum [5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=059c2a4d8e164dccc3078e49e7f286023b019a98 --- regards Yura Sokolov y.soko...@postgrespro.ru funny.fal...@gmail.com

Re: BufferAlloc: don't take two simultaneous locks

В Сб, 02/10/2021 в 01:25 +0300, Yura Sokolov пишет: > Good day. > > I found some opportunity in Buffer Manager code in BufferAlloc > function: > - When valid buffer is evicted, BufferAlloc acquires two partition > lwlocks: for partition for evicted block is in and partiti

Fix BUG #17335: Duplicate result rows in Gather node

/m/17500.1551669976%40sss.pgh.pa.us [2] https://postgr.es/m/CAKJS1f_Wt_tL3S32R3wpU86zQjuHfbnZbFt0eqm%3DqcRFcdbLvw%40mail.gmail.com regards Yura Sokolov y.soko...@postgrespro.ru funny.fal...@gmail.com From 47c6e161de4fc9d2d6eff45f427ebf49b4c9d11c Mon Sep 17 00:00:00 2001 From: Yura Sokolov Date: Mon, 2

Re: XTS cipher mode for cluster file encryption

В Вт, 26/10/2021 в 11:08 +0800, Sasasu пишет: > On 2021/10/26 04:32, Yura Sokolov wrote: > > And among others Adiantum looks best: it is fast even without hardware > > acceleration, > > No, AES is fast on modern high-end hardware. > > on X86 AMD 3700X > type

Re: XTS cipher mode for cluster file encryption

В Пн, 25/10/2021 в 12:12 -0400, Stephen Frost пишет: > Greetings, > > * Yura Sokolov (y.soko...@postgrespro.ru) wrote: > > В Чт, 21/10/2021 в 13:28 -0400, Stephen Frost пишет: > > > I really don't think this is necessary. Similar to PageSetChecksumCopy > > > and

Re: [PoC] Improve dead tuple storage for lazy vacuum

intset replacement certainly. Using same trick from radix_to_key it will store tids efficiently: shift = pg_ceil_log2_32(MaxHeapTuplesPerPage); tid_i = ItemPointerGetOffsetNumber(tid); tid_i |= ItemPointerGetBlockNumber(tid) << shift; Will do today's evening. regards Yura Sokol

Re: [PoC] Improve dead tuple storage for lazy vacuum

ny-falcon/pgtools/tree/svtm/bdbench regards, Yura SokolovFrom 3a6c96cc705b1af412cf9300be6f676f6c5e4aa6 Mon Sep 17 00:00:00 2001 From: Yura Sokolov Date: Sun, 25 Jul 2021 03:06:48 +0300 Subject: [PATCH] svtm - specialized vacuum tid map --- bdbench/Makefile | 2 +- bdbench/bdbench.c |

Re: Fix BUG #17335: Duplicate result rows in Gather node

В Сб, 01/01/2022 в 15:19 +1300, David Rowley пишет: > On Fri, 31 Dec 2021 at 00:14, Yura Sokolov wrote: > > Problem: > > - Append path is created with explicitely parallel_aware = true > > - It has two child, one is trivial, other is parallel_aware = false . > >

Re: Error "initial slot snapshot too large" in create replication slot

ents should be written about new usage case for `takenDuringRecovery`. May be this field should be renamed at all? And there are checks for `takenDuringRecovery` in `heapgetpage` and `heapam_scan_sample_next_tuple`. Are this checks affected by the change? Neither the preceding discussion nor commit message answer me. --- regards Yura Sokolov Postgres Professional y.soko...@postgrespro.ru funny.fal...@gmail.com

Re: BufferAlloc: don't take two simultaneous locks

В Пт, 11/03/2022 в 15:30 +0900, Kyotaro Horiguchi пишет: > At Thu, 03 Mar 2022 01:35:57 +0300, Yura Sokolov > wrote in > > В Вт, 01/03/2022 в 10:24 +0300, Yura Sokolov пишет: > > > Ok, here is v4. > > > > And here is v5. > > > > First, there

Re: BufferAlloc: don't take two simultaneous locks

and !reuse cases but > BufTableInsert doesn't and always does HASH_ASSIGN. That looks > odd. We should use HASH_ENTER here. Thus I think it is more > reasonable that HASH_ENTRY uses the stashed entry if exists and > needed, or returns it to freelist if exists but not needed. > > What do you think about this? Well... I don't like it but I don't mind either. Code in HASH_ENTER and HASH_ASSIGN cases differs much. On the other hand, probably it is possible to merge it carefuly. I'll try. - regards Yura Sokolov

Re: BufferAlloc: don't take two simultaneous locks

killer?) > Subject: [PATCH 3/3] reduce memory allocation for non-partitioned dynahash > > memory allocation -> memory allocations For each dynahash instance single allocation were reduced. I think, 'memory allocation' is correct. Plural will be reduce memory allocations for non

Re: BufferAlloc: don't take two simultaneous locks

s, which need to be > > treated > >* just like permanent relations. > >* > >* The usage_count starts out at 1 so that the buffer can survive one > >* clock-sweep pass. > > But if you think the current commet is fine, I don't

Re: BufferAlloc: don't take two simultaneous locks

? 32bit for 32 partitions. But wouldn't bitmap became contention point itself? > No need to do something for the possible deviation issue. --- regards Yura Sokolov

Re: BufferAlloc: don't take two simultaneous locks

В Пн, 14/03/2022 в 17:12 +0900, Kyotaro Horiguchi пишет: > At Mon, 14 Mar 2022 09:15:11 +0300, Yura Sokolov > wrote in > > В Пн, 14/03/2022 в 14:31 +0900, Kyotaro Horiguchi пишет: > > > I'd like to ask you to remove nalloced from partitions then add a > > >

Re: BufferAlloc: don't take two simultaneous locks

В Вт, 15/03/2022 в 13:47 +0300, Yura Sokolov пишет: > В Вт, 15/03/2022 в 16:25 +0900, Kyotaro Horiguchi пишет: > > Thanks for the new version. > > > > At Tue, 15 Mar 2022 08:07:39 +0300, Yura Sokolov > > wrote in > > > В Пн, 14/03/2022 в 14:57 +0300, Yur

Re: BufferAlloc: don't take two simultaneous locks

В Ср, 16/03/2022 в 12:07 +0900, Kyotaro Horiguchi пишет: > At Tue, 15 Mar 2022 13:47:17 +0300, Yura Sokolov > wrote in > > В Вт, 15/03/2022 в 16:25 +0900, Kyotaro Horiguchi пишет: > > > Hmm. v8 returns stashed element with original patition index when the > >

Declare PG_HAVE_8BYTE_SINGLE_COPY_ATOMICITY for aarch64

PG_HAVE_8BYTE_SINGLE_COPY_ATOMICITY for aarch64 [1] https://documentation-service.arm.com/static/61fbe8f4fa8173727a1b734e https://developer.arm.com/documentation/ddi0487/latest --- regards Yura Sokolov Postgres Professional y.soko...@postgrespro.ru funny.fal...@gmail.com From

Re: BufferAlloc: don't take two simultaneous locks

В Пн, 14/03/2022 в 14:57 +0300, Yura Sokolov пишет: > В Пн, 14/03/2022 в 17:12 +0900, Kyotaro Horiguchi пишет: > > At Mon, 14 Mar 2022 09:15:11 +0300, Yura Sokolov > > wrote in > > > В Пн, 14/03/2022 в 14:31 +0900, Kyotaro Horiguchi пишет: > > > > I'd lik

Re: BufferAlloc: don't take two simultaneous locks

В Вт, 15/03/2022 в 16:25 +0900, Kyotaro Horiguchi пишет: > Thanks for the new version. > > At Tue, 15 Mar 2022 08:07:39 +0300, Yura Sokolov > wrote in > > В Пн, 14/03/2022 в 14:57 +0300, Yura Sokolov пишет: > > > В Пн, 14/03/2022 в 17:12 +0900, Kyotaro Horiguchi пи

Re: BufferAlloc: don't take two simultaneous locks

В Вт, 15/03/2022 в 13:47 +0300, Yura Sokolov пишет: > В Вт, 15/03/2022 в 16:25 +0900, Kyotaro Horiguchi пишет: > > > I lost access to Xeon 8354H, so returned to old Xeon X5675. > > ... > > > Strange thing: both master and patched version has higher > > > peak tp

Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.

В Сб, 12/02/2022 в 16:56 +0530, Bharath Rupireddy пишет: > On Fri, Feb 11, 2022 at 7:56 PM Yura Sokolov wrote: > > В Сб, 16/10/2021 в 16:37 +0530, Bharath Rupireddy пишет: > > > On Thu, Oct 14, 2021 at 10:56 AM Fujii Masao > > > wrote: > > > > On 20

Re: BufferAlloc: don't take two simultaneous locks

Hello, Simon. В Пт, 25/02/2022 в 04:35 +, Simon Riggs пишет: > On Mon, 21 Feb 2022 at 08:06, Yura Sokolov wrote: > > Good day, Kyotaro Horiguchi and hackers. > > > > В Чт, 17/02/2022 в 14:16 +0900, Kyotaro Horiguchi пишет: > > > At Wed, 16 Feb 2022 10:40:56 +03

Re: BufferAlloc: don't take two simultaneous locks

Hello, Andres В Пт, 25/02/2022 в 00:04 -0800, Andres Freund пишет: > Hi, > > On 2022-02-21 11:06:49 +0300, Yura Sokolov wrote: > > From 04b07d0627ec65ba3327dc8338d59dbd15c405d8 Mon Sep 17 00:00:00 2001 > > From: Yura Sokolov > > Date: Mon, 21 Feb 2022 08:49:03 +

Re: BufferAlloc: don't take two simultaneous locks

В Пт, 25/02/2022 в 09:01 -0800, Andres Freund пишет: > Hi, > > On 2022-02-25 12:51:22 +0300, Yura Sokolov wrote: > > > > +* The usage_count starts out at 1 so that the buffer can > > > > survive one > > > > +* clock-sweep pass. > &

Re: BufferAlloc: don't take two simultaneous locks

В Пт, 25/02/2022 в 09:38 +, Simon Riggs пишет: > On Fri, 25 Feb 2022 at 09:24, Yura Sokolov wrote: > > > > This approach is cleaner than v1, but should also perform better > > > because there will be a 1:1 relationship between a buffer and its > > >

Re: BufferAlloc: don't take two simultaneous locks

wHashValue, > LWLock *oldPartitionLock, > LWLock *newPartitionLock > ); Interesting suggestion, thanks. I'll think about. It has downside of bringing LWLock knowdlege to dynahash.c . But otherwise looks smart. - regards, Yura Sokolov

Re: BufferAlloc: don't take two simultaneous locks

and will attach graphs with next message. Patch is attached here. -- regards, Yura Sokolov Postgres Professional y.soko...@postgrespro.ru funny.fal...@gmail.com From 7f430bdaa748456ed6b59f16f32ac0ea55644a66 Mon Sep 17 00:00:00 2001 From: Yura Sokolov Date: Fri, 14 Jan 2022 02:28:36 +0300

Re: BufferAlloc: don't take two simultaneous locks

В Вт, 01/03/2022 в 10:24 +0300, Yura Sokolov пишет: > Ok, here is v4. And here is v5. First, there was compilation error in Assert in dynahash.c . Excuse me for not checking before sending previous version. Second, I add third commit that reduces HASHHDR allocation size for non-partitio

Re: BufferAlloc: don't take two simultaneous locks

Good day, Kyotaro Horiguchi and hackers. В Чт, 17/02/2022 в 14:16 +0900, Kyotaro Horiguchi пишет: > At Wed, 16 Feb 2022 10:40:56 +0300, Yura Sokolov > wrote in > > Hello, all. > > > > I thought about patch simplification, and tested version > > without BufTable

Re: Speed up transaction completion faster after many relations are accessed in a transaction

source owners usually form stack, so usually when owner searches for itself it is last added to list. Then `dlist_foreach` will find it sooner if it were added to the head. regards - Yura Sokolov Postgres Professional y.soko...@postgrespro.ru funny.fal...@gmail.com

Re: BufferAlloc: don't take two simultaneous locks

В Чт, 17/03/2022 в 12:02 +0900, Kyotaro Horiguchi пишет: > At Wed, 16 Mar 2022 14:11:58 +0300, Yura Sokolov > wrote in > > В Ср, 16/03/2022 в 12:07 +0900, Kyotaro Horiguchi пишет: > > > At Tue, 15 Mar 2022 13:47:17 +0300, Yura Sokolov > > > wrote in &

Jumble Query with COERCE_SQL_SYNTAX

Good day. v14 introduced the way to get original text for some kind of expressions using new 'funcformat' - COERCE_SQL_SYNTAX: - EXTRACT(part from timestamp) - (text IS [form] NORMALIZED) and others. Mentioned EXTRACT and NORMALIZED statements has parts, that are not usual arguments but some

Re: Accommodate startup process in a separate ProcState array slot instead of in MaxBackends slots.

orm an Assert(when_i_am_startup_proc && > autovacuum_not_running) (this looks a bit dirty though)? Instead, we > can just enlarge the array in the master and be confident about the > fact that the startup process always has one dedicated slot. But this slot wont be used for most of cluster life. It will be just waste. And `Assert(there_is_startup_proc && autovacuum_not_running)` has value on its own, hasn't it? So why doesn't add it with comment. regards, Yura Sokolov

Re: Fix BUG #17335: Duplicate result rows in Gather node

В Чт, 20/01/2022 в 09:32 +1300, David Rowley пишет: > On Fri, 31 Dec 2021 at 00:14, Yura Sokolov wrote: > > Suggested quick (and valid) fix in the patch attached: > > - If Append has single child, then copy its parallel awareness. > > I've been looking at this and I've gon

Re: Fix BUG #17335: Duplicate result rows in Gather node

В Вс, 23/01/2022 в 14:56 +0300, Yura Sokolov пишет: > В Чт, 20/01/2022 в 09:32 +1300, David Rowley пишет: > > On Fri, 31 Dec 2021 at 00:14, Yura Sokolov wrote: > > > Suggested quick (and valid) fix in the patch attached: > > > - If Append has single child, then

Re: Fix BUG #17335: Duplicate result rows in Gather node

В Пн, 24/01/2022 в 16:24 +0300, Yura Sokolov пишет: > В Вс, 23/01/2022 в 14:56 +0300, Yura Sokolov пишет: > > В Чт, 20/01/2022 в 09:32 +1300, David Rowley пишет: > > > On Fri, 31 Dec 2021 at 00:14, Yura Sokolov > > > wrote: > > > > Suggested quic

Re: Fix BUG #17335: Duplicate result rows in Gather node

В Вт, 25/01/2022 в 21:20 +1300, David Rowley пишет: > On Tue, 25 Jan 2022 at 20:03, David Rowley wrote: > > On Tue, 25 Jan 2022 at 17:35, Yura Sokolov wrote: > > > And another attempt to fix tests volatility. > > > > FWIW, I had not really seen the point in addin

Re: BufferAlloc: don't take two simultaneous locks

В Чт, 07/04/2022 в 16:55 +0900, Kyotaro Horiguchi пишет: > Hi, Yura. > > At Wed, 06 Apr 2022 16:17:28 +0300, Yura Sokolov > wrot > e in > > Ok, I got access to stronger server, did the benchmark, found weird > > things, and so here is new version :-) >

Re: BufferAlloc: don't take two simultaneous locks

Good day, Kyotaoro-san. Good day, hackers. В Вс, 20/03/2022 в 12:38 +0300, Yura Sokolov пишет: > В Чт, 17/03/2022 в 12:02 +0900, Kyotaro Horiguchi пишет: > > At Wed, 16 Mar 2022 14:11:58 +0300, Yura Sokolov > > wrote in > > > В Ср, 16/03/2022 в 12:07 +0900,

Re: Vectorization of some functions and improving pg_list interface

24.08.2023 17:07, Maxim Orlov wrote: Hi! Recently, I've been playing around with pg_lists and realize how annoying (maybe, I was a bit tired) some stuff related to the lists. For an example, see this code List *l1 = list_make4(1, 2, 3, 4), *l2 = list_make4(5, 6, 7, 8),

Re: Vectorization of some functions and improving pg_list interface

06.09.2023 13:24, Yura Sokolov wrote: 24.08.2023 17:07, Maxim Orlov wrote: Hi! Recently, I've been playing around with pg_lists and realize how annoying (maybe, I was a bit tired) some stuff related to the lists. For an example, see this code List *l1 = list_make4(1, 2, 3, 4

Re: BufferAlloc: don't take two simultaneous locks

В Чт, 21/04/2022 в 16:24 -0400, Robert Haas пишет: > On Thu, Apr 21, 2022 at 5:04 AM Yura Sokolov wrote: > > $ pid=`ps x | awk '/checkpointer/ && !/awk/ { print $1 }'` > > $ gdb -p $pid -batch -ex 'p SharedBufHash->hctl->allocated.value' > > > > $1

Re: BufferAlloc: don't take two simultaneous locks

Btw, I've runned tests on EPYC (80 cores). 1 key per select conns | master | patch-v11 | master 1G | patch-v11 1G ++++ 1 | 29053 | 28959 | 26715 | 25631 2 | 53714 | 53002 | 55211 |

  1   2   >