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

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: 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: 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: 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

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

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

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

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: 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

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: [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: [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] 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] 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)

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)

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] 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)

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] 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] 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

<    1   2