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

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: Add PortalDrop in exec_execute_message

seek-able? regards, tom lane regards Yura Sokolov

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

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

Add PortalDrop in exec_execute_message

y name check is enough? Can client reset or seek portal with empty name? regards, Sokolov Yura aka funny_falconrequire 'pg' c1 = PG.connect(host: "localhost", dbname: "postgres") c2 = PG.connect(host: "localhost", dbname: "postgres") c3 = PG.connect(host: "

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. >>> >>> Duri

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

believe my algorithm is not the best. Clock-Pro and ARC shows better results on that traces. Tiny-LFU - cache admission algorithm - may be even more efficient (in term of evictions). But results should be rechecked with PostgreSQL traces. My algorithm will be just least invasive for current code, imho. With regards, Sokolov Yura signature.asc Description: OpenPGP digital signature

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)

tatic? May be then there is no need in separate raw representation and hash table. I may try to fill hash table directly in GetSnapshotData instead of lazy filling. Though it will increase time under lock, so it is debatable and should be carefully measured. I'll look at a bug in CopySnapshot soon.

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

be moving forward. Updated numbers are (same benchmark on same notebook, but with new master, new ubuntu and later patch version) (average among 6 runs): master - 16135tps with templated qsort - 16199tps with bucket sort - 16956tps Difference is still measurable, but less significant. I don

<    1   2