Re: Pluggable toaster

; Teodor Sigaev E-mail: teo...@sigaev.ru >WWW: http://www.sigaev.ru/ > > > -- Nikita Malakhov Postgres Professional https://postgrespro.ru/ 0001-Fix-toast_tuple_externalize.patch Description: Binary data 0002-Fix-alignment-of-custom-TOAST-pointers.patch Description: Binary data

Re: Pluggable toaster

Hi all! Simon, thank you for your review. I'll try to give a brief explanation on some topics you've mentioned. My colleagues would correct me if I miss the point and provide some more details. >Agreed, Oleg has made some very clear analysis of the value of having >a higher degree of control over

Re: [PATCH] Compression dictionaries for JSONB

r extendable > TOAST? Maybe something we could add to src/test/modules similarly to > how we test SLRU, background workers, etc. > """ > > Since there was not much activity since then (for 3 months) I don't > really see how to process further. > > -- > Best regards, > Aleksander Alekseev > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

024-01 Commitfest. > > > > Hi, This patch has a CF status of "Needs Review" [1], but it seems > > there were CFbot test failures last time it was run [2]. Please have a > > look and post an updated version if necessary. > > > > == > > [1] https://commitfest.postgresql.org/46/4456/ > > [2] https://cirrus-ci.com/task/5581154296791040 > > > > Kind Regards, > > Peter Smith. > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Shared detoast Datum proposal

HASH_ENTER - according to comments it could throw an OOM error, so I've changed it to HASH_ENTER_NULL to avoid new errors. In this case we would just have the value not cached without an error. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.r

Re: POC: Extension for adding distributed tracing - pg_tracing

where. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Shared detoast Datum proposal

t need the whole value to be detoasted and kept in memory. What do you think? -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Shared detoast Datum proposal

lly, it is a subject for a separate topic, as soon as I make it work on the current master we'll propose it to the community. Andy, thank you! I'll check the last patch set out and reply in a day or two. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Shared detoast Datum proposal

in several days and would report on the result here. There are also comments on the code itself, I'd write them a bit later. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Shared detoast Datum proposal

't be detoasted (as a shared value)? > > Grarantee may be wrong word. The difference in my mind are: > 1. plan shape have better potential to know the user case of datum, > since we know the plan tree and knows the rows pass to a given node. > 2. Planning time effort is cheaper than run-time effort. > 3. eviction in my method is not as important as it is in TOAST cache > method since it is reset per slot, so usually it doesn't hit limit in > fact. But as a cache, it does. > 4. use up to memory limit we set in TOAST cache case. > > >>> In any case, my concern is more about having to do this when creating > >>> the plan at all, the code complexity etc. Not just because it might > have > >>> performance impact. > >> > >> I think the main trade-off is TOAST cache method is pretty non-invasive > >> but can't control the eviction well, the impacts includes: > >> 1. may evicting the datum we want and kept the datum we don't need. > > > > This applies to any eviction algorithm, not just LRU. Ultimately what > > matters is whether we have in the cache the most often used values, i.e. > > the hit ratio (perhaps in combination with how expensive detoasting that > > particular entry was). > > Correct, just that I am doubtful about design a LOCAL CACHE for USER > DATA with the reason I described above. > > At last, thanks for your attention, really appreciated about it! > > -- > Best Regards > Andy Fan > > > > -- Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Shared detoast Datum proposal

Hi, In addition to the previous message - for the toast_fetch_datum_slice the first (seems obvious) way is to detoast the whole value, save it to cache and get slices from it on demand. I have another one on my mind, but have to play with it first. -- Regards, Nikita Malakhov Postgres

Re: Shared detoast Datum proposal

we do not have enough memory and added checks for if the value was stored or not. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Re[2]: [PATCH] Optional OR REPLACE in CREATE OPERATOR statement

ink about IF NOT > EXISTS option? > > Thanks, > > -- > Svetlana Derevyanko > Postgres Professional: http://www.postgrespro.com > The Russian Postgres Company > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: ALTER TABLE uses a bistate but not for toast tables

> Unpatched: > 5000 | postgres | pg_toast_96188840 | t > => 40MB of shared buffers > > Patched: > 2048 | postgres | pg_toast_17097 | t > > Note that a similar problem seems to exist in COPY ... but I can't see > how to fix that one. > > -- > Justin > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

es using 32-bit values, Please have a look. I'd be grateful for some further directions. GIT branch with this feature, rebased onto current master: https://github.com/postgrespro/postgres/tree/toast_64bit On Wed, Dec 7, 2022 at 12:00 AM Nikita Malakhov wrote: > Hi hackers! > > Here'

Re: collect_corrupt_items_vacuum.patch

r, but I >> > don't know why it matters what the latest completed XID is. >> >> Daniel, it seems to me that this thread is waiting for some input from >> you, based on the remarks of Tom and Robert. Are you planning to do >> so? This is marked as a bug fix, so I have moved this item to the >> next CF for now. >> -- >> Michael >> > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Pluggable toaster

t; > dropping Toaster possible if there is no data TOASTed with it, along with > > several other major changes. It will be available in this (I hope so) or > the > > following, if I won't make it in time, commitfest. > > Looking forward to v24! > > This is a major change so I hope there will be more feedback from > other people on the mailing list. > > -- > Best regards, > Aleksander Alekseev > -- Regards, -- Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: New strategies for freezing, advancing relfrozenxid early

c, but broad-reaching, nitpick about terms regarding > "skipping strategy". That's phrased as a kind of negative -- what we're > *not* doing. Many times I had to pause and compute in my head what we're > *doing*, i.e. the "scanning strategy". For example

Re: On login trigger: take three

sted in the previous email. Well, that’s the repeatability level we have. > This convinces me even more that the observed level of performance drop is > acceptable. > -- > best regards, > Mikhail A. Gribkov > > e-mail: youzh...@gmail.com > *http://www.flickr.com/photos/youzhick/albums > <http://www.flickr.com/photos/youzhick/albums>* > http://www.strava.com/athletes/5085772 > phone: +7(916)604-71-12 > Telegram: @youzhick > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Patch: Global Unique Index

but it does not wait for the > transaction lock held by insertion on index X. > > 3) when an insertion inserting a conflict value on index Y, > 3.1) it waits for buffer block lock if the lock has been held by > the insertion on index X. > 3.2) then, it waits for transaction lock until the insertion on > index X is done. > > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: New strategies for freezing, advancing relfrozenxid early

hat you didn't > editorialize too much while just moving code around. +1 from me. > > > -- > Jeff Davis > PostgreSQL Contributor Team - AWS > > > > > -- Regards, -- Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: meson and tmp_install

instead allow to run the tests against the build > directory itself. The temp-install adds a fair bit of overhead and > failure potential. The only reason we need it is that a) initdb and a > few other programs insist that postgres needs to be in the same > directory b) cont

Re: meson and tmp_install

9:22 PM Andres Freund wrote: > Hi, > > On 2022-12-20 21:11:26 +0300, Nikita Malakhov wrote: > > Didn't know where to ask, so I've chosen this thread - there is no any > > documentation on meson build platform in PostgreSQL docs. > > There is now: > https://www

Re: Array initialisation notation in syscache.c

understood why it works, but it does indeed seem to work and > > this should make cfbot green. > > This looks like a good improvement to me. > > (I have also thought about having this generated from the catalog > definition files somehow, but one step at a time ...) > > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

Hi hackers! Any suggestions on the previous message (64-bit toast value ID with individual counters)? On Tue, Dec 13, 2022 at 1:41 PM Nikita Malakhov wrote: > Hi hackers! > > I've prepared a patch with a 64-bit TOAST Value ID. It is a kind of > prototype > and needs some

Re: ARRNELEMS Out-of-bounds possible errors

ELEMS(ent); > memcpy(ptr, ARRPTR(ent), nel * sizeof(int32)); > } > > Sources possibly affecteds: > contrib\cube\cube.c > contrib\intarray\_intbig_gist.c > contrib\intarray\_int_bool.c > contrib\intarray\_int_gin.c > contrib\intarray\_int_gist.c > contrib\intarray\_i

Re: ARRNELEMS Out-of-bounds possible errors

code needs to be revised. On Fri, Dec 23, 2022 at 1:20 AM Ranier Vilela wrote: > Em qui., 22 de dez. de 2022 às 15:45, Nikita Malakhov > escreveu: > >> Hi, >> >> Actually, there would be much more sources affected, like >> nbytes += subbytes[out

Re: ARRNELEMS Out-of-bounds possible errors

he commit. > > No.. It seems to me that the commit didn't change its behavior in that > regard. > > > Of course teaching Coverity not to issue the false warnings would be > > another actual issue that we should do, maybe. > > -- > Kyotaro Horiguchi > NTT Open Source Software Center > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: ARRNELEMS Out-of-bounds possible errors

Hi, My bad, I was misleaded by unconditional return in ereturn_domain. Sorry for the noise. On Sat, Dec 24, 2022 at 7:05 PM Tom Lane wrote: > Nikita Malakhov writes: > > Even with null context it does not turn to ereport, and returns dummy > value > > Read the code. Arr

Passing relation metadata to Exec routine

/ -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Passing relation metadata to Exec routine

agree that passing these parameters in a backdoor fashion is not very transparent and user-friendly, too. On Tue, Dec 27, 2022 at 12:56 AM Tom Lane wrote: > Nikita Malakhov writes: > > While working on Pluggable TOAST [1] we found out that creation > > of new relation with CREATE T

Re: split TOAST support out of postgres.h

> I dunno, #3 seems kind of unprincipled. Also, since fmgr.h is included > so widely, I doubt it is buying very much in terms of reducing header > footprint. How bad is it to do #2? > > regards, tom lane > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: How to define template types in PostgreSQL

MODULE_PATHNAME', 'Set_ne' ... > ... > > In the case of arrays, ranges, and multiranges, PostgreSQL avoids this > redundancy using pseudo-types such as anyarray, anyrange, anymultirange, ... > > Is there a possibility that we can also define pseudo types such as

Re: Pluggable toaster

Hi! Fails due to recent changes. Working on it. On Sat, Jan 14, 2023 at 9:56 AM vignesh C wrote: > On Sun, 8 Jan 2023 at 01:40, Nikita Malakhov wrote: > > > > Hi! > > > > Thank you for your attention. > > I've rebased the patchset onto the latest master

Re: Inconsistency in vacuum behavior

check for > its child. > The check will be performed later in vacuum_rel(), but after > vacuum_open_relation(), which leads to hang in the second session. > > Is it intended? Why don't we perform vacuum_is_permitted_for_relation() > check for inheritors in expand_vacuum_rel()? > > -- > Best regards, > Alexander Pyhalov, > Postgres Professional > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Inconsistency in vacuum behavior

quire the lock. Cheers! On Mon, Jan 16, 2023 at 4:48 PM Nikita Malakhov wrote: > Hi! > > I've checked this expand_vacuum_rel() and made a quick fix for this.Here's > the result of the test: > > postgres@postgres=# set role regress_vacuum_conflict; > SET > Time

Re: Inconsistency in vacuum behavior

objections? On Mon, Jan 16, 2023 at 7:46 PM Alexander Pyhalov wrote: > Nikita Malakhov писал 2023-01-16 17:26: > > Hi! > > > > Here's the patch that fixes this case, please check it out. > > The patch adds vacuum_is_permitted_for_relation() check before adding >

Re: Inconsistency in vacuum behavior

Hi hackers! Alexander found a very good issue. Please check the solution above. Any objections? It's a production case, please review, any thoughts and objections are welcome. On Mon, Jan 16, 2023 at 8:15 PM Alexander Pyhalov wrote: > Nikita Malakhov писал 2023-01-16 20:12

Re: Inconsistency in vacuum behavior

Hi! I've found the discussion you'd mentioned before, checking now. On Thu, Jan 19, 2023 at 4:49 AM Justin Pryzby wrote: > On Mon, Jan 16, 2023 at 08:12:18PM +0300, Nikita Malakhov wrote: > > Hi, > > > > Currently there is no error in this case, so additional thr

Re: Inconsistency in vacuum behavior

Justin Pryzby писал 2023-01-19 04:49: > > On Mon, Jan 16, 2023 at 08:12:18PM +0300, Nikita Malakhov wrote: > >> Hi, > >> > >> Currently there is no error in this case, so additional thrown error > >> would > >> require a new test. > >> Besid

JsonPath version bits

ts is it possible to use to store a version value? Thanks! -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: JsonPath version bits

Hi hackers! Could the 1 byte from the JsonPath header be used to store version? Or how many bits from the header could be used for the version value? On Mon, Mar 27, 2023 at 12:54 PM Nikita Malakhov wrote: > Hi hackers! > > I've got a question on the JsonPath header - currently t

Re: SQL JSON path enhanced numeric literals

> > > > since that's different from the main lexer's syntax. > > done > > > Perhaps it's worth mentioning that difference in the docs. > > done > > > Otherwise, this looks good to me. > > committed > > > > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: SQL/JSON revisited

ror = > NULL; } > ; > > Surely this can be made cleaner. > > By the way -- that comment about clauses being non-standard, can you > spot exactly *which* clauses that comment applies to? > > -- > Álvaro Herrera PostgreSQL Developer — > https://www.EnterpriseDB.com/ > "El número de instalaciones de UNIX se ha elevado a 10, > y se espera que este número aumente" (UPM, 1972) > > > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: [PATCH] Compression dictionaries for JSONB

n these > > columns in a single JSONB column. > > It is unreasonable to expect this to be possible, due to e.g. > partitioning resulting in columns that share compressable patters to > be on different physical tables. > > > * TOAST currently doesn't support ZSTD. IMO this is not a big deal and > > adding the corresponding support can be discussed separately. > > * If memory serves, there were not so many free bits left in TOAST > > pointers. The pointers don't store a storage strategy though so > > hopefully this will not be a problem. We'll see. > > The toast pointer must store enough info about the compression used to > decompress the datum, which implies it needs to store the compression > algorithm used, and a reference to the compression dictionary (if > any). I think the idea about introducing a new toast pointer type (in > the custom toast patch) wasn't bad per se, and that change would allow > us to carry more or different info in the header. > > Kind regards, > > Matthias van de Meent > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Doc limitation update proposal: include out-of-line OID usage per TOAST-ed columns

t/16722-93043fb459a41073%40postgresql.org > > > [1] https://www.postgresql.org/message-id/CAN-LCVPRvRzxeUdYdDCZ7UwZQs1NmZpqBUCd%3D%2BRdMPFTyt-bRQ%40mail.gmail.com -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

Hi! No, it wasn't. It was a proposal, I thought I'd get some feedback on it before sending it to commitfest. On Sat, Apr 22, 2023 at 6:17 PM Gurjeet Singh wrote: > On Thu, Dec 22, 2022 at 10:07 AM Nikita Malakhov > wrote: > > Any suggestions on the previous message (64-b

Re: Doc limitation update proposal: include out-of-line OID usage per TOAST-ed columns

: > On Fri, Apr 21, 2023 at 12:14 AM Nikita Malakhov > wrote: > > This limitation applies not only to wide tables - it also applies to > tables where TOASTed values > > are updated very often. You would soon be out of available TOAST value > ID because in case of &g

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

s will be more beneficial for the community in > the long term. > > Thoughts? > > [1]: https://commitfest.postgresql.org/43/3626/ > > -- > Best regards, > Aleksander Alekseev > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: [PATCH] Compression dictionaries for JSONB

07tX%3DnVCw%40mail.gmail.com > > -- > Best regards, > Aleksander Alekseev > -- Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

RFI: Extending the TOAST Pointer

org/message-id/flat/CAJ7c6TOtAB0z1UrksvGTStNE-herK-43bj22%3D5xVBg7S4vr5rQ%40mail.gmail.com> [4] BUG #16722: PG hanging on COPY when table has close to 2^32 toasts in the table. <https://www.postgresql.org/message-id/flat/16722-93043fb459a41073%40postgresql.org> -- Regards, Nikita

Generic JSON API

r of GSON is Postgres Pro developer Nikita Glukhov with the guidance of Oleg Bartunov. We're waiting for community' review, and of course proposals, advices, questions and further discussions. Thank you! -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/ 3_tmp_stack_

Re: jsonpath syntax extensions

guess it'll get moved forward again. I don't think "returned with > feedback" is helpful given there's been basically no feedback :( > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Pluggable toaster

/task/4710272324599808?logs=cores#L44 > > Andres > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Pluggable toaster

Is 'git apply' not a valid way to apply such patches? We'll try to straighten these issues out asap. Thank you! On Mon, Apr 4, 2022 at 7:40 PM Robert Haas wrote: > On Mon, Apr 4, 2022 at 12:13 PM Nikita Malakhov wrote: > > I'm really sorry. Messed up some code w

Re: Pluggable toaster

fast appending to existing bytea value. Appended tail stored directly in toaster pointer, if there is enough space to do it. Working on refactoring according to your recommendations. Thank you! On Mon, Apr 4, 2022 at 11:18 PM Robert Haas wrote: > On Mon, Apr 4, 2022 at 4:05 PM Nikita Malakho

Re: Pluggable toaster

n Wed, Apr 13, 2022 at 9:55 PM Nikita Malakhov wrote: > Hi, > I reworked previous patch set according to recommendations. Patches > are generated by format-patch and applied by git am. Patches are based on > master from 03.11. Also, now we've got clean branch with incremental >

Re: remaining sql/json patches

to process this kind of error correctly. Please check attached patch set. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ v23-0003-1-transformJsonExprCommon-fixup.patch Description: Binary data v23-0003-2-json-query-coercion-override.patch Description: Binary data

Re: remaining sql/json patches

efore or while processing the request. The connection to the server was lost. Attempting reset: Failed. The connection to the server was lost. Attempting reset: Failed. Time: 6.858 ms @!> We're currently looking into this case. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

Hi, Sorry, forgot to mention above - patches from our patch set should be applied onto SQL/JSON part 3 - v22-0003-SQL-JSON-query-functions.patch, thus they are numbered as v23-0003-1 and -2. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Pro et contra of preserving pg_proc oids during pg_upgrade

Hi, Thank you very much, I'll check it out. It looks like the getObjectIdentity() used in pg_identify_object() could do. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

RFC: Pluggable TOAST

://www.postgresql.org/message-id/flat/CAN-LCVMq2X%3Dfhx7KLxfeDyb3P%2BBXuCkHC0g%3D9GF%2BJD4izfVa0Q%40mail.gmail.com -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

ost_eval->jcstate->coercion && > + (post_eval->jcstate->coercion->via_io || > + post_eval->jcstate->coercion->via_populate)) > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: RFC: Pluggable TOAST

large JSON objects. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

Hi, The main goal was to correctly process invalid queries (as in examples above). I'm not sure this could be done in type input functions. I thought that some coercions could be checked before evaluating expressions for saving reasons. -- Regards, Nikita Malakhov Postgres Professiona

Re: RFC: Pluggable TOAST

other enhancements we already have. Previous topic was not of any help here. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

Hi, Agreed on the latter, that must not be the part of it for sure. Would think on how to make this part correct. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: RFC: Pluggable TOAST

I have to rethink our approach to the TOAST enhancements according to it. Thanks a lot! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: remaining sql/json patches

Hi! According to the discussion above, I've added the 'proerrsafe' attribute to the PG_PROC relation. The same was done some time ago by Nikita Glukhov but this part was reverted. This is a WIP patch, I am new to this part of Postgres, so please correct me if I'm going the w

Re: remaining sql/json patches

sion. (For example, >needing a catversion bump every time we convert one more function, >or an extension version bump to convert extensions.) so should figure out another way to do it. Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: RFC: Pluggable TOAST

omponents of TOAST through functions that can then be used by >type-specific toast support functions. >Note that this would be opt-in for a type, thus all functions that use >that type's internals should be aware of the different on-disk format >for toasted values and should th

Re: RFC: Pluggable TOAST

. Or should not? -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Patch: Global Unique Index

Hi! Please advise on the status of this patch set - are there any improvements? Is there any work going on? Thanks! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Table AM Interface Enhancements

t; > here I suggest adding Assert(rel->rd_amcache == NULL) (or maybe better an > error report) after calling free_rd_amcache to be sure the custom > implementation has done what it should do. > > Also, I think some brief documentation about writing this custom method is > quite relev

Re: [Proposal] global sequence implemented by snowflake ID

ter > (snowflake IDs guarantee unicity with their machine ID), replication > may not be necessary because the sequence implementation may be able > to ensure that no replication is required from the start. > -- > Michael > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Avoid detoast overhead when possible

Hi! There's a view from the other angle - detoast just attributes that are needed (partial detoast), with optimized storage mechanics for JSONb. I'm preparing a patch for it, so maybe the best results could be acquired by combining these two techniques. What do you think? -- Regar

Re: Avoid detoast overhead when possible

ue in some other memory or existing-slot-in-place for > different sistuation, that would requires more expr expression changes > and planner changes. I just checked all the queries in my hand, the > current design can cover all of them. > > -- > Best Regards > Andy Fan > > > > -- Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Avoid detoast overhead when possible

(3 rows) Time: 327.132 ms postgres@postgres=# explain analyze select big->'1' from b; QUERY PLAN Seq Scan on b (cost=0.00..19.51 rows=10

Re: RFI: Extending the TOAST Pointer

iated. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ 0001_custom_toast_pointer_v1.patch Description: Binary data

Re: POC: Extension for adding distributed tracing - pg_tracing

could be done by adding SQL function to add and remove query ID into a list (even array would do) stored in top tracing context. Great job, thank you! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Is a clearer memory lifespan for outerTuple and innerTuple useful?

MergeJoinState. Since the code was writen by Tom at > 2005, so add Tom to the cc-list. > > > -- > Best Regards > Andy Fan > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: introduce dynamic shared memory registry

or re-load the extension? -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

ing for the whole session would immediately result in thousands of trace spans in the system with throughput like hundreds or even thousands of tps, when we need, say, to trace a single problematic query. Thank you! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

tests, but I don't > think this is a preferred solution. > > Speaking of the tests I suggest adding a bit more comments before > every (or most) of the queries. Figuring out what they test could be > not particularly straightforward for somebody who will make changes > after the patch will be accepted. > > [1]: http://cfbot.cputube.org/ > [2]: https://github.com/afiskon/pgscripts/ > > -- > Best regards, > Aleksander Alekseev > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Pro et contra of preserving pg_proc oids during pg_upgrade

Hi hackers! Please advise on the idea of preserving pg_proc oids during pg_upgrade, in a way like relfilenodes, type id and so on. What are possible downsides of such a solution? Thanks! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Pro et contra of preserving pg_proc oids during pg_upgrade

pg_upgrade (pg_dump and func/procedure creation function). I've read previous threads about using regproc, and agree that this is not a very good case anyway, but I haven't found any serious obstacles that forbid modifying pg_upgrade this way. -- Regards, Nikita Malakhov Postgres Profes

Re: Pro et contra of preserving pg_proc oids during pg_upgrade

ed by some extension and saved and re-processed automatically or by user's request, but without bothering user with these internal keys. The main question - maybe, are there pitfalls of which I am not aware of? Thanks for your replies! -- Regards, Nikita Malakhov Postgres Professional T

Re: Pro et contra of preserving pg_proc oids during pg_upgrade

pg_upgrade. Actually, I've asked here because there are several references to PG_PROC oids from other tables in the system catalog, so I was worried if this logic could break something I do not know about. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Pluggable toaster

d data which could be very heavy if Toaster is assigned to a widely used datatype, and we're looking forward to any ideas. >So you suggest we move all of this to toaster? I'd say -1 to that, >because it makes it much harder to e.g. add custom compression method, etc. Original compres

Re: Pluggable toaster

require extensions. Also, the name Toaster is a little bit misleading because it intends that data is being sliced, but it is not always the case, to be toasted a piece of bread must not necessarily be sliced. Regards, -- Nikita Malakhov Postgres Professional https://postgrespro.ru/ On Tue, Jan 18, 2

Re: Pluggable toaster

able. One can imagine a new table AM for the main table that > wants to use something different for TOAST. So, I don't think it's > right to imagine that the choice of TOASTer depends solely on the > column data type. I'm not really sure how this should work exactly ... >

Re: Pluggable toaster

oal is to merely implement "type-aware > sub-TOASTers" then compression dictionaries [1] arguably provide the > same value with MUCH less complexity. > > -- > Best regards, > Aleksander Alekseev > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: collect_corrupt_items_vacuum.patch

; don't know why it matters what the latest completed XID is. > > Daniel, it seems to me that this thread is waiting for some input from > you, based on the remarks of Tom and Robert. Are you planning to do > so? This is marked as a bug fix, so I have moved this item to the > next CF for now. > -- > Michael > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

[PATCH] Infinite loop while acquiring new TOAST Oid

stems. Quick fix for this problem is limiting GetNewOidWithIndex loops to some reasonable amount defined by related macro and returning error if there is still no available Oid. Please check attached patch, any feedback is appreciated. -- Regards, Nikita Malakhov Postgres Professional

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

ry thankful for any advice on this. On Mon, Nov 28, 2022 at 11:36 PM Andres Freund wrote: > Hi, > > On 2022-11-28 18:34:20 +0300, Nikita Malakhov wrote: > > While working on Pluggable TOAST we've detected a defective behavior > > on tables with large amounts of TOASTed da

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

. Please check attached patch, any feedback is > >> appreciated. > > > This feels like the wrong spot to tackle the issue. > > Yeah, that is completely horrid. It does not remove the existing failure > mode, just changes it to have worse consequences. > > regards, tom lane > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

s not relevant compared to the size of toasted datums. > > Greetings, > > Andres Freund > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

large amounts of data in use). On Tue, Nov 29, 2022 at 1:12 AM Nikita Malakhov wrote: > Hi, > > I'll check that tomorrow. If it is so then there won't be a problem keeping > old tables without re-toasting. > > On Tue, Nov 29, 2022 at 1:10 AM Andres Freund wrote: >

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

er tables have many IDs. (Optional, could do later.) > Thank you! -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: [PATCH] Infinite loop while acquiring new TOAST Oid

T value ID; - individual ID counters for each TOAST table, being cached for faster access and lookup of maximum TOAST ID in use after server restart. https://github.com/postgrespro/postgres/tree/toast_64bit -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

  1   2   3   >