Re: Avoiding data loss with synchronous replication

23 июля 2021 г., в 22:54, Bossart, Nathan написал(а):On 7/23/21, 4:33 AM, "Andrey Borodin" wrote:Thanks for you interest in the topic. I think in the thread [0] we almost agreed on general design.The only left question is that we want to threat pg_ctl stop and kill SIGTERM diff

Re: Avoiding data loss with synchronous replication

ecessary to wait. If the client wish to execute more commands they can open new connection or set synchronous_commit to desired level in first place. Canceling committed locally transaction will not be possible anyway. Thanks! Best regards, Andrey Borodin. [0] https://www.postgresql.org/message-id/flat/6a052e81060824a8286148b1165bafedbd7c86cd.camel%40j-davis.com#415dc2f7d41b8a251b419256407bb64d

Re: How is this possible "publication does not exist"

ror reporting. While source of the problem was allegedly in low max_replication_slots, users were getting only this error about relcache_callback_list. Maybe we could fix this particular error by deduplicating callbacks? Best regards, Andrey Borodin. 0001-Avoid-duplication-in-relcache-and-syscache-callbacks.patch Description: Binary data

Logical replication error "no record found" /* shouldn't happen */

! Best regards, Andrey Borodin. 0001-Improve-error-reporting-of-ReadPageInternal.patch Description: Binary data

Re: Synchronous commit behavior during network outage

> 3 июля 2021 г., в 23:44, Jeff Davis написал(а): > > On Sat, 2021-07-03 at 14:06 +0500, Andrey Borodin wrote: >>> But until you've disabled sync rep, the primary will essentially be >>> down for writes whether using this new feature or not. Even if you >&g

Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)

low > users who belong to the right security role to SET and ALTER SYSTEM SET > variables without being a superuser. I'm not sure, but maybe we should allow replication role to change session_replication_role? Best regards, Andrey Borodin.

Re: Synchronous commit behavior during network outage

> 3 июля 2021 г., в 01:15, Jeff Davis написал(а): > > On Fri, 2021-07-02 at 11:39 +0500, Andrey Borodin wrote: >> If the failover happens due to unresponsive node we cannot just turn >> off sync rep. We need to have some spare connections for that (number >> of st

Re: Synchronous commit behavior during network outage

> 2 июля 2021 г., в 10:59, Jeff Davis написал(а): > > On Wed, 2021-06-30 at 17:28 +0500, Andrey Borodin wrote: >>> My patch also covers the backend termination case. Is there a >>> reason >>> you left that case out? >> >> Yes, backend ter

Re: New committers: Daniel Gustafsson and John Naylor

success and few bugs. Congratulations to Daniel and John! Many features with few bugs :) Best regards, Andrey Borodin.

Re: Synchronous commit behavior during network outage

> 29 июня 2021 г., в 23:35, Jeff Davis написал(а): > > On Tue, 2021-06-29 at 11:48 +0500, Andrey Borodin wrote: >>> 29 июня 2021 г., в 03:56, Jeff Davis >>> написал(а): >>> >>> The patch may be somewhat controversial, so I'll wait for feedb

Re: Synchronous commit behavior during network outage

> 29 июня 2021 г., в 03:56, Jeff Davis написал(а): > > The patch may be somewhat controversial, so I'll wait for feedback > before documenting it properly. The patch seems similar to [0]. But I like your wording :) I'd be happy if we go with any version of these idea.

Re: Different compression methods for FPI

> 29 июня 2021 г., в 08:41, Michael Paquier написал(а): > > Now that v15 is open for business, I have looked again at this stuff > this morning and committed the LZ4 part That's great, thanks Michael! Best regards, Andrey Borodin.

Re: Different compression methods for FPI

upthread): > https://www.postgresql.org/message-id/20210308.173242.463790587797836129.horikyota.ntt%40gmail.com +1. Best regards, Andrey Borodin.

Re: pglz compression performance, take two

imilar architectures like Arduino. I've benchmarked the patch with "REINDEX table pgbench_accounts" on pgbench -i of scale 100. wal_compression was on, other settings were default. Without patch it takes ~11055.077 ms on my machine, with patch it takes ~9512.411 ms, 14% s

Re: Cosmic ray hits integerset

o explain this as not a single-event upset, but integer overflow in 30-bits mode of simple8b somewhere. But found nothing so far. Actual error is in bit 35, and next mode is 60-bit mode. Looks like cosmic ray to me too. Best regards, Andrey Borodin.

Re: Different compression methods for FPI

ession methods? Or is it too long string for waldump output? 3. Can we exclude lz4 from config if it's not supported by the build? Thanks! Best regards, Andrey Borodin.

Supply restore_command to pg_rewind via CLI argument

ss config to 'postgres -C restore_command' run? From my POV adding --target-restore-command is simplest way, I can extract corresponding portions from original patch. Thanks! Best regards, Andrey Borodin. [0] https://www.postgresql.org/message-id/flat/CAPpHfduUqKLr2CRpcpH

Re: Different compression methods for FPI

> 17 июня 2021 г., в 11:57, Michael Paquier написал(а): > > On Thu, Jun 17, 2021 at 11:45:37AM +0500, Andrey Borodin wrote: >> Konstantin, Daniil and Justin are working on compressing libpq >> [0]. That would make walsender compress WAL automatically. >> And

Re: Different compression methods for FPI

> 17 июня 2021 г., в 06:19, Michael Paquier написал(а): > > On Wed, Jun 16, 2021 at 01:17:26PM +0500, Andrey Borodin wrote: >> I agree that allowing just lz4 - is already a huge step ahead. > > Yeah, I am tempted to just add LZ4 as a first step as the patch > footpri

Re: Different compression methods for FPI

h record. > If it helps the compression, we should probably start WAL-logging b-tree > index build in larger batches, too. Here's PoC for this [0]. But benchmark results are HW-dependent. Best regards, Andrey Borodin. https://www.postgresql.org/message-id/flat/41822E78-48EE-41AE-

Re: Different compression methods for FPI

efault. This could simplify FPI code. Thanks! Best regards, Andrey Borodin.

Re: Different compression methods for FPI

more than pglz: > |Time: 1612.874 ms (00:01.613) > |wal_bytes| 12397123 > > zstd(6) is slower than lz4, but compresses better than anything but zlib. > |Time: 1808.881 ms (00:01.809) > |wal_bytes| 6395993 I was wrong about zlib: it has its point on Pareto fronti

Re: GiST operator class for bool

would be cool to have gist build and gist_btree support it together, but there was many parts and we could did not finish it before feature freeze. Best regards, Andrey Borodin.

Re: GiST operator class for bool

sql.org/31/2824/ ... Thanks! Best regards, Andrey Borodin.

Re: Different compression methods for FPI

tio than Zstd. Zstd is actively developed. There is Google's Brotli codec. It is comparable to Zstd. What kind of deeper study do we want to do? Would it make sense to run our own benchmarks? Or, perhaps, review other codecs? In my opinion, anything that is sent over network or written to

Re: rand48 replacement

> 24 мая 2021 г., в 15:31, Fabien COELHO написал(а): > > > - NOT to invent a new design! Radical version of this argument would be to use de-facto standard and ubiquitous MT19937. Though, I suspect, it's not optimal solution to the date. Best regards, Andrey Borodin.

Re: Synchronous commit behavior during network outage

on, that a multinode (>=3 nodes) cluster is necessary. PostgreSQL does not provide and fault detection and automatic failover. Documenting anything wrt failover is the responsibility of HA tool. Thanks! Best regards, Andrey Borodin.

Re: .ready and .done files considered harmful

had a table with files that need to be archived, a table with registered archivers and a function to say "archiver number X has done its job on file Y". Archiver could listen to some archiver channel while sleeping or something like that. Thanks! Best regards, Andrey Borodin.

Re: Incorrect snapshots while promoting hot standby node when 2PC is used

> 3 мая 2021 г., в 23:10, Andres Freund написал(а): > > Hi, > > On 2021-05-01 17:35:09 +0500, Andrey Borodin wrote: >> I'm investigating somewhat resemblant case. >> We have an OLTP sharded installation where shards are almost always under >> rebalanc

Re: Incorrect snapshots while promoting hot standby node when 2PC is used

bserve similar cases 3-5 times a year. To the date no data was lost due to this, but it's somewhat annoying. BTW I'd say that such things are an argument for back-porting pg_surgery and heapcheck to old versions. Thanks! Best regards, Andrey Borodin.

Re: GISTSTATE is too large

alty call at all: there are many GiST-based access methods that want to see all items together to choose insertion subtree (e.g. R*-tree and RR-tree). Calling penalty function for each tuple on page often is not a good idea at all. Thanks! Best regards, Andrey Borodin.

Re: Allowing to create LEAKPROOF functions to non-superuser

in DSL queries. It have no obvious side effects. Maybe we could hack it by exploiting timestamp overflow, but I doubt it's practically usable. Thanks! Best regards, Andrey Borodin. [0] https://github.com/ivan816/simple-1c/blob/f2e5ce78b98f70f30039fd3de79308a59d432fc2/Simple1C/Impl/Sql/SchemaMapping/Simple1cSchemaCreator.cs#L74

Re: Disallow cancellation of waiting for synchronous replication

ch sounds as follows: transaction effects should not be observable on primary until requirements of synchronous_commit are satisfied. E.g. even if user issues cancel of committed locally transaction, we should not release locks held by this transaction. What unexpected surprises do you see in this model? Thanks for reviewing! Best regards, Andrey Borodin.

Re: Synchronous commit behavior during network outage

protect from this on HA tool's side. Best regards, Andrey Borodin. [0] https://commitfest.postgresql.org/33/2402/

Re: ML-based indexing ("The Case for Learned Index Structures", a paper from Google)

lating key differences and, probably, code of an extension. Best regards, Andrey Borodin.

Re: ML-based indexing ("The Case for Learned Index Structures", a paper from Google)

some vectorisation. The concurrency is from a regular B-tree, of cause. This is my pet project. So, unsurprisingly, I've done only parts of big plan :) I would appreciate any help. Thanks! Best regards, Andrey Borodin. [0] https://pgm.di.unipi.it/ [1] https://github.com/x4m/pg2m

Re: Allowing to create LEAKPROOF functions to non-superuser

> 13 апр. 2021 г., в 00:01, Andres Freund написал(а): > > Hi, > > On 2021-04-12 23:51:02 +0300, Andrey Borodin wrote: >> Do I risk having some extra superusers in my installation if I allow >> everyone to create LEAKPROOF functions? > > I think that depends

Re: Allowing to create LEAKPROOF functions to non-superuser

It's a client's VM after all and all software is open source. But it opens a way to attack control plane. Which in turn opens a way for clients to attack each other. And we really do not want it. Thanks! Best regards, Andrey Borodin.

Re: Allowing to create LEAKPROOF functions to non-superuser

elaxing requirements in upstream. Do I risk having some extra superusers in my installation if I allow everyone to create LEAKPROOF functions? Thanks! Best regards, Andrey Borodin.

Allowing to create LEAKPROOF functions to non-superuser

upstream Postgres? I'll appreciate any comments. Thanks! Best regards, Andrey Borodin. [0] https://www.postgresql.org/message-id/flat/CACqFVBbx6PDq%2B%3DvHM0n78kHzn8tvOM-kGO_2q_q0zNAMT%2BTzdA%40mail.gmail.com

Re: MultiXact\SLRU buffers configuration

> 8 апр. 2021 г., в 15:22, Thomas Munro написал(а): > > On Thu, Apr 8, 2021 at 7:24 PM Andrey Borodin wrote: >> I agree that this version of eviction seems much more effective and less >> intrusive than RR. And it's still LRU, which is important for subsyst

Re: MultiXact\SLRU buffers configuration

, MAX_REPLACEMENT_SEARCH);" does not reflect changes. Besides this patch looks good to me. Thanks! Best regards, Andrey Borodin.

Re: Yet another fast GiST build

it checks? Best regards, Andrey Borodin.

Re: MultiXact\SLRU buffers configuration

> 7 апр. 2021 г., в 14:44, Andrey Borodin написал(а): > > Maybe instead of fully associative cache with random replacement we could use > 1-associative cache? > i.e. each page can reside only in one spcific buffer slot. If there's > something else - evict it. >

Re: Yet another fast GiST build

*not* > call byteacmp(), but bitcmp(). Because it operates on the original datatype > stored in the table. +1 Thanks for investigating this. If I understand things right, adding test values with different lengths of bit sequences would not uncover the problem anyway? Best regards, Andrey Borodin.

Re: MultiXact\SLRU buffers configuration

hed. > Maybe instead of fully associative cache with random replacement we could use 1-associative cache? i.e. each page can reside only in one spcific buffer slot. If there's something else - evict it. I think this would be as efficient as RR cache. And it's s fast. Best regards, Andrey Borodin.

Re: MultiXact\SLRU buffers configuration

t; higher? I changed default due to some experiments with https://www.postgresql.org/message-id/flat/20210115220744.GA24457%40alvherre.pgsql In fact most important part of that thread was removing the cap, which is done by the patchset now. Thanks! Best regards, Andrey Borodin.

Re: MultiXact\SLRU buffers configuration

> 29 марта 2021 г., в 11:26, Andrey Borodin написал(а): > > My TODO list: > 1. Try to break patch set v13-[0001-0004] > 2. Think how to measure performance of linear search versus hash search in > SLRU buffer mapping. Hi Thomas! I'm still doing my homework. And to this

Re: MultiXact\SLRU buffers configuration

> 29 марта 2021 г., в 02:15, Thomas Munro написал(а): > > On Sat, Mar 27, 2021 at 6:31 PM Andrey Borodin wrote: >>> 27 марта 2021 г., в 01:26, Thomas Munro написал(а): >>> , and murmurhash which is inlineable and >>> branch-free. > >> I think p

Re: MultiXact\SLRU buffers configuration

> 27 марта 2021 г., в 01:26, Thomas Munro написал(а): > > On Sat, Mar 27, 2021 at 4:52 AM Andrey Borodin wrote: >> Some thoughts on HashTable patch: >> 1. Can we allocate bigger hashtable to reduce probability of collisions? > > Yeah, good idea, might require s

Re: MultiXact\SLRU buffers configuration

> 26 марта 2021 г., в 11:00, Andrey Borodin написал(а): > >> I'm not saying the 0002 patch is bug-free yet though, it's a bit finickity. > I think the idea of speeding up linear search is really really good for > scaling SLRUs. It's not even about im

Re: MultiXact\SLRU buffers configuration

l degradation under certain circumstances. Bigger cache really saves SLAs :) I'll look into the patch more closely this weekend. Thank you! Best regards, Andrey Borodin. [0] https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW

Re: Reduce the time required for a database recovery from archive.

> 18 марта 2021 г., в 20:04, David Steele написал(а): > it would be nice to support an interface that simply says to the > restore_command, "go get 1gb of WAL and write the files here." +1 to redesigning restore_command and archive_command. Best regards, Andrey Borodin.

Re: Different compression methods for FPI

trictly necessary for this patch set. The problem in tests arises if we turn on wal_compression, absolutely independently from wal compression method. We turn on wal_compression in this test only for CI purposes. Thanks! Best regards, Andrey Borodin.

Re: MultiXact\SLRU buffers configuration

fixed: > > > > s/Tipically/Typically/ > > s/asincronous/asyncronous/ > > s/confugured/configured/ > > s/substrnsactions/substransactions/ > > Thanks, Gilles! Fixed. Best regards, Andrey Borodin. v10-0001-Make-all-SLRU-buffer-sizes-configurable.patch Description: Binary data

Re: pg_amcheck contrib application

ould be perfect if we could do backup verification at cost of corruption monitoring (and not vice versa, which is trivial). Best regards, Andrey Borodin.

Re: Disallow cancellation of waiting for synchronous replication

Thanks for looking into this! > 11 марта 2021 г., в 19:15, Fujii Masao > написал(а): > > > > On 2020/12/09 18:07, Andrey Borodin wrote: >>> 9 июня 2020 г., в 23:32, Jeff Davis написал(а): >>> >>> >> After using a patch for a while it bec

Re: pg_amcheck contrib application

iles_command='backup-tool list-files %backup_id'. And pg_amcheck could then fetch bare minimum of what is needed. I see that this is somewhat orthogonal idea, but from my POV interesting one. Best regards, Andrey Borodin.

Re: Yet another fast GiST build

h with sortsupport routines for btree_gist contrib module. Here's its version which needs review. Thanks for bringing this up! Best regards, Andrey Borodin. v5-0001-Sortsupport-for-sorting-GiST-build-for-gist_btree.patch Description: Binary data

Re: Different compression methods for FPI

e wal_compression = {off, fpi, all}. Best regards, Andrey Borodin.

Re: 011_crash_recovery.pl intermittently fails

he root cause. So, test verifies guarantee that is not provided (durability of aborted transactions)? Maybe flip it to test that transaction effects are not committed\visible? Best regards, Andrey Borodin.

Re: 011_crash_recovery.pl intermittently fails

t investigate the case at that moment, but I think that it would be good to run recovery regression tests with compression too. Best regards, Andrey Borodin.

Re: GiST comment improvement

y section of src/backend/access/gist/README. And maybe even to doc/src/sgml/acronyms.sgml. Just for connectivity. Thanks! Best regards, Andrey Borodin.

Re: libpq compression

ompression context often does not help to mitigate CRIME. Thanks! Best regards, Andrey Borodin.

Different compression methods for FPI

nt methods. It seems to me that only TAP tests are suitable for this. Thanks! Best regards, Andrey Borodin. [0] https://www.postgresql.org/message-id/323B1B01-DA42-419F-A99C-23E2C162D53B%40yandex-team.ru 0001-Use-different-compression-methods-for-FPIs.patch Description: Binary data

Re: MultiXact\SLRU buffers configuration

time to time there can be problems with subtransactions cured by extending subtrans SLRU. Let's make all SLRUs configurable? PFA patch with draft of these changes. Best regards, Andrey Borodin. [0] https://www.postgresql.org/message-id/flat/20210115220744.GA24457%40alvherre.pgsql v9-0001-Make-all-SLRU-buffer-sizes-configurable.patch Description: Binary data

Re: increase size of pg_commit_ts buffers

> 16 янв. 2021 г., в 03:07, Alvaro Herrera написал(а): > > Andrey Borodin already has a patch to change the behavior for > multixact, which is something we should perhaps also do. I now notice > that they're also reporting a bug in that thread ... sigh I've tried

Re: pglz compression performance, take two

earchCatCache1 0.79% postgres [.] LWLockAttemptLock 0.78% postgres [.] GetSnapshotData Overall cluster runs 862tps (52KtpmC, though only 26KtmpC is qualified on 2K warehouses). Thanks! Best regards, Andrey Borodin.

Re: Why does creating logical replication subscriptions require superuser?

[offlist] > 22 янв. 2021 г., в 13:16, Thomas Kellerer написал(а): > > Andrey Borodin schrieb am 22.01.2021 um 08:32: > >> Replication is running under superuser and e.g. one can add system catalog >> to subscription. >> Or exploit this fact other way. Having su

Re: Why does creating logical replication subscriptions require superuser?

nnects as the user that created the > subscription, so would that prevent potential vulnerabilities in any way? Subscription operations must run with privileges of user that created it. All other ways are error prone and leave subscriptions only in superuser's arsenal. Thanks! Best regards, Andrey Borodin.

Re: recovering from "found xmin ... from before relfrozenxid ..."

> 18 янв. 2021 г., в 18:54, Robert Haas написал(а): > > On Sat, Jan 16, 2021 at 10:41 AM Andrey Borodin wrote: >> Does anyone maintain opensource pg_surgery analogs for released versions of >> PG? >> It seems to me I'll have to use something like this and

Re: recovering from "found xmin ... from before relfrozenxid ..."

Hi hackers! Does anyone maintain opensource pg_surgery analogs for released versions of PG? It seems to me I'll have to use something like this and I just though that I should consider pg_surgery in favour of our pg_dirty_hands. Thanks! Best regards, Andrey Borodin.

Re: Yet another fast GiST build

these parameters should be of type int in SQL. Item offsets cannot exceed maximum block size of 32768. And even 32768/sizeof(ItemId). Thus overflow is impossible. Interesting question is wether pageinspect should protect itself from corrupted input? Generating description from bogus tuple, probably, can go wrong. Best regards, Andrey Borodin.

Re: Yet another fast GiST build

eep it > in sync (except maybe with bottom-up deletion, where that it at least > isn't straightforward/mechanical). Sound great! Best regards, Andrey Borodin. 0001-Add-bool-column-for-LP_DEAF-flag-to-GiST-pageinspect.patch Description: Binary data

Re: Yet another fast GiST build

which consists of float8's. Since I already > pushed this, I'm going to just wait and see what the buildfarm says, and fix > if needed. I think the fix is going to be to just remove the test for the > bytea-variant, it doesn't seem that important to test. Maybe we can j

Re: libpq compression

nd a compressionlibs struct would also be included. I'm >> planning to do something like this with the next revision of my patchset. >> > It will be great to have such common preliminary patch including zstd support. +1. I'd also rebase my WAL FPI patch on top of common code. Best regards, Andrey Borodin.

Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding

ible space, though. I seem to me that not committing an insurance patch is not a mistake. Let's abandon slru-truncate-t-insurance for now. >> Fix certainly worth backpatching. > > I'll push it on Saturday, probably. Thanks! Best regards, Andrey Borodin.

Re: Yet another fast GiST build

ll bytea tests run correctly on 32bit\different-endian systems? Best regards, Andrey Borodin.

Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding

own bugs, and potentially contains unknown bugs. I can't reason because of such uncertainty. I've tried to look for any potential problem and as for now I see none. Chances are is doing code less error-prone. Fix certainly worth backpatching. Thanks! Best regards, Andrey Borodin.

Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding

tion. One more thing: retention point at 3/4 of overall space (half of wraparound) seems more or less random to me. Why not 5/8 or 9/16? Can you please send revised patches with fixes? Thanks! Best regards, Andrey Borodin.

Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding

oing to keep all segements forever and range still will be continuous. Or am I missing something? Thanks! Best regards, Andrey Borodin.

Re: archive status ".ready" files may be created too early

e it back. Maybe just hold the lock a little longer? 3. Things that are done by GetLastNotifiedSegment() could just be atomic read? I'm not sure it's common practice. Thanks! Best regards, Andrey Borodin.

Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding

> 1 янв. 2021 г., в 23:05, Andrey Borodin написал(а): > > I've found this thread in CF looking for something to review. We discussed patches with Noah offlist. I'm resending summary to list. There are two patches: 1. slru-truncate-modulo-v5.patch 2. slru-truncate-t-ins

Re: zstd compression for pg_dump

ct compressLibs I think this directive would be correct. +// #ifdef HAVE_LIBZ? Here's extra comment // && errno == ENOENT) [PATCH 06/20] pg_dump: zstd compression I'd propose to build with Zstd by default. It seems other patches do it this way. Though, I there are possible downsides. Thanks for working on this! We will have very IO-efficient Postgres :) Best regards, Andrey Borodin.

Re: archive status ".ready" files may be created too early

4030/16384 blk 140 rmgr: Transaction len (rec/tot): 46/46, tx: 3890578936, lsn: 1C02F/B4000AF0, prev 1C02F/B4000A68, desc: COMMIT 2020-11-12 15:27:32.509443 MSK Best regards, Andrey Borodin.

Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding

ed tests into assert checking like in SlruPagePrecedesUnitTests()? SLRU seems no near simple, BTW. The only simple place is naive caching algorithm. I remember there was a thread to do relations from SLRUs. Best regards, Andrey Borodin.

Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding

this connection? Best regards, Andrey Borodin.

Re: [PATCH] Simplify permission checking logic in user.c

g those patches and extensions. Let's start to work together with community. Let's address issues that thread[0] faced and restart it. Happy New Year :) Best regards, Andrey Borodin. [0] https://www.postgresql.org/message-id/flat/f41d93b6-69ba-fa05-c91a-045bafa5f832%402ndquadrant.com#636c800abc6f464c388db7f532a389ba

Re: [PATCH] Simplify permission checking logic in user.c

+1 again. I hope we will return to the topic soon. Best regards, Andrey Borodin. [0] https://www.postgresql.org/message-id/flat/1269681541151271%40myt5-68ad52a76c91.qloud-c.yandex.net

Re: pglz compression performance, take two

nicity, which > lesser good => less good > allign: align Fixed. > > This comment I couldn't understand: > +* As initial compare for short matches compares 4 bytes then for the > end > +* of stream length of match should be cut I've reworded comme

Re: [HACKERS] Custom compression methods

> 28 дек. 2020 г., в 11:14, Andrey Borodin написал(а): > >> Thanks for the patch. Maybe we can allow setting custom compression >> methods for wal compression as well. > > No, unfortunately, we can't use truly custom methods. Custom compression > handlers ar

Re: [HACKERS] Custom compression methods

> 28 дек. 2020 г., в 10:20, Dilip Kumar написал(а): > > On Sun, Dec 27, 2020 at 12:40 PM Andrey Borodin wrote: >> >> >> >>> 25 дек. 2020 г., в 14:34, Dilip Kumar написал(а): >>> >>> >>> >>> >>> >

Re: PoC Refactor AM analyse API

ent table_scan_analyze_next_block()/table_scan_analyze_next_tuple() API assumes too much about AM implementation. But why do you pass int natts and VacAttrStats **stats to acquire_sample_rows()? Is it of any use? It seems to break abstraction too. Best regards, Andrey Borodin.

Re: [HACKERS] Custom compression methods

ginal patchset. Best regards, Andrey Borodin. v16-0007-Add-Lz4-compression-to-WAL-FPIs.patch Description: Binary data

Re: pglz compression performance, take two

> 12 дек. 2020 г., в 22:47, Andrey Borodin написал(а): > > I've cleaned up comments, checked that memory alignment stuff actually make sense for 32-bit ARM (according to Godbolt) and did some more code cleanup. PFA v2 patch. I'm still in doubt should I register this

Re: libpq compression

e's a memory > leak somewhere - that we're not resetting/freeing some piece of memory, or > so. Why would zstd need so much memory? It seems like a pretty serious > disadvantage, so how could it become so popular? AFAIK it's 700 clients. Does not seem like super high price for big traffic\latency reduction. Best regards, Andrey Borodin.

Re: MultiXact\SLRU buffers configuration

> 13 дек. 2020 г., в 22:24, Andrey Borodin написал(а): > > > >> 13 дек. 2020 г., в 14:17, Gilles Darold написал(а): >> >> I've done more review on these patches. > > Thanks, Gilles! I'll incorporate all your fixes to patchset. PFA patches

Re: MultiXact\SLRU buffers configuration

ultXact offset in corner case"? The problem manifests on Standby when Primary is heavily loaded with MultiXactOffsetControlLock. Thanks! Best regards, Andrey Borodin.

Re: Speeding up GIST index creation for tsvectors

ke __builtin_* etc wherever possible. Meanwhile there are at least 4 incarnation of hemdistsign() functions that are quite similar. I'd propose to refactor them somehow... Thanks! Best regards, Andrey Borodin.

Re: pglz compression performance, take two

> 9 дек. 2020 г., в 12:44, Andrey Borodin написал(а): > PFA the patch with some editorialisation by me. > I saw some reports of bottlenecking in pglz WAL compression [1]. I've checked that on my machine simple test echo "wal_compression = on" >> $PGDATA/po

<    1   2   3   4   5   6   7   >