Re: Replace magic numbers with strategy numbers for B-tree indexes

I've made this just for BT strategies macros and touched only 2 source files to make a correct but simple example. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ v3-0001-poc-get-rid-of-magic-numbers.patch Description: Binary data

Detoast iterators -take 2

d. [1] https://www.postgresql.org/message-id/flat/CAL-OGks_onzpc9M9bXPCztMofWULcFkyeCeKiAgXzwRL8kXiag%40mail.gmail.com -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ v1-0001-detoast-iterator.patch Description: Binary data

Detoast iterators - take 2

d. [1] https://www.postgresql.org/message-id/flat/CAL-OGks_onzpc9M9bXPCztMofWULcFkyeCeKiAgXzwRL8kXiag%40mail.gmail.com -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ v1-0001-detoast-iterator.patch Description: Binary data

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

ps my vision of things is too simple, but I cannot think about a > good reason that would justify making this code more complicated than > it already is. > -- > Michael > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Dead code with short varlenas in toast_save_datum()

b text); > ALTER TABLE temp_tbl SET (toast_tuple_target = 128); > ALTER TABLE temp_tbl ALTER COLUMN a SET STORAGE EXTERNAL; > ALTER TABLE temp_tbl ALTER COLUMN b SET STORAGE EXTERNAL; > INSERT INTO temp_tbl values(repeat('a', 4000), repeat('a', 120)); > > -- > Nikhil Veldanda > > > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Dead code with short varlenas in toast_save_datum()

d as > being usable by out-of-core code, so depending on how fancy things are > being done a TOAST relation could use a short varatt for an insert. > > Thoughts? > -- > Michael > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

during update), this is a subject to change. And logical replication, as I mentioned earlier, does not have any means for replicating toast diffs. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

o use multiple TOAST tables, with different variations - by type, by column and as-is just as an extensible storage. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

which will be not possible separately from the main heap with direct > toast tid pointers anyway. > > Please take a look and poke holes in it ! > > > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ v1-0001-direct-tids-toast.patch Description: Binary data

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

Hi Michael, I'm currently debugging POC direct tids TOAST patch (on top of your branch), will mail it in a day or two. On Tue, Jul 15, 2025 at 3:56 AM Michael Paquier wrote: > On Mon, Jul 14, 2025 at 09:01:28AM +0300, Nikita Malakhov wrote: > > Cool, toast tables are subject

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

ems there is a promising way to solve it once and for all! Have to mention though that we encountered issues in logical replication when we made toast values updatable. Also researching direct tids implementation. Cheers! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres

Re: Some ExecSeqScan optimizations

Hi! Andres, thank you for the explanation about the locks. I've already tried to pass scan keys and saw that it is quite expensive. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Some ExecSeqScan optimizations

inscan * (and this is very bad) - so, here we do not check are keys ok or not. Have you considered passing scan keys like it is done in IndexScan? Thanks! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

Hi, Hannu, we have some thoughts on direct tids storage, it was some time ago and done by another developer, so I have to look. I'll share it as soon as I find it, if you are interested. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

we got an array of 19 members with only 2 valid ones. What do you think about having an individual TOAST value id counter per relation instead of using a common one? I think this is a very promising approach, but a decision must be made where it should be stored. -- Regards, Nikita Malakhov

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

external_data = ondisk_oid_create_external_data, }, }; Shouldn't TOAST_POINTER_INT8_SIZE be replaced with TOAST_POINTER_OID_SIZE? Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

lt;https://www.postgresql.org/message-id/flat/224711f9-83b7-a307-b17f-4457ab73aa0a%40sigaev.ru> -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ On Fri, Jul 4, 2025 at 2:03 PM Hannu Krosing wrote: > Hi Michael > > I'll tak

Re: Custom reloptions in TableAM

Hi! Thank you very much, I'll check it out. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Custom reloptions in TableAM

reloptions */ rdopts = (myAMOptions *) build_reloptions(reloptions, validate, my_relopt_kind, sizeof(myAMOptions), tab, lengthof(tab)); return (bytea *) rdopts; } Hope you'll find it useful. Advice and objections are welcome. POC patch in attachment. -- Regards, Nikita Malakhov Postgres

Re: Proposal: Global Index for PostgreSQL

lt;https://www.postgresql.org/message-id/flat/184879c5306.12490ea581628934.7312528450011769010%40highgo.ca> Thank you! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: ZStandard (with dictionaries) compression support for TOAST compression

uding locks while working with this table resulting in performance degradation, and so on. > > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: ZStandard (with dictionaries) compression support for TOAST compression

arding the Zstd implementation you propose - does it provide a possibility for partial decompression? > > Thanks! [1] https://www.postgresql.org/message-id/flat/CAN-LCVMq2X%3Dfhx7KLxfeDyb3P%2BBXuCkHC0g%3D9GF%2BJD4izfVa0Q%40mail.gmail.com -- Regards, Nikita Malakhov Postgres Professional The Rus

Re: Introduce some randomness to autovacuum

from the previous iteration. On Fri, Apr 25, 2025 at 6:04 PM wenhui qiu wrote: > Hi，I like your idea，It would be even better if the weights could be taken > according to the larger tables > > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: SQL:2023 JSON simplified accessor support

.373 ms INSERT 0 1 Time: 3.299 ms INSERT 0 1 Time: 2.532 ms INSERT 0 1 Time: 2.453 ms Original master: postgres@postgres=# select (t.y).b.c.d.e from t; ERROR: column notation .b applied to type jsonb, which is not a composite type LINE 1: select (t.y).b.c.d.e from t; ^ Time:

Re: Current master hangs under the debugger after Parallel Seq Scan (Linux, MacOS)

state=0x562bec781858, econtext=, isnull=) at execExprInterp.c:625 625 return state->resvalue; Although, the process continues to work normally after gdb is detached from it. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: SQL/JSON json_table plan clause

Hi Amit! Thank you for your feedback, I'll check it out in a couple of days and reply. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Considering fractional paths in Append node

Hi! No objections. Alexander, thank you! -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: SQL/JSON json_table plan clause

Hi Amit! No, JSON_TABLE is ok. I've meant that in the previous approach to PLAN clause implementation there were some wrong tests. On Tue, Feb 4, 2025 at 6:05 AM Amit Langote wrote: > Hi Nikita, > > On Wed, Dec 18, 2024 at 12:11 AM Nikita Malakhov > wrote: > > >

Precheck to consider path costs for partial paths

message-id/flat/SEZPR06MB649422CDEBEBBA3915154EE58A232%40SEZPR06MB6494.apcprd06.prod.outlook.com -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ v1-0001-ppath-precheck.patch Description: Binary data

Re: remaining sql/json patches

Hi! Amit, ok, I'll start a new thread with this patch after I deal with an issue on plan execution, I've found it during testing. On Mon, Nov 11, 2024 at 3:29 AM Amit Langote wrote: > Hi Nikita, > > On Sat, Nov 9, 2024 at 5:22 PM Nikita Malakhov wrote: > > > > H

Re: remaining sql/json patches

to > transformJsonOutput() does make sense? > > + if (get_typtype(ret->typid) == TYPTYPE_PSEUDO) > + ereport(ERROR, > + errcode(ERRCODE_FEATURE_NOT_SUPPORTED), > + errmsg("returning pseudo-types is not supported in > SQL/JSON functions")); > + >

Re: Considering fractional paths in Append node

you for your opinion and interest! I've corrected failing test and created a patch at Commitfest: https://commitfest.postgresql.org/51/5361/ Please check. On Tue, Oct 29, 2024 at 2:38 AM Andy Fan wrote: > Nikita Malakhov writes: > > > Hi, > > > > Andy, thank you,

Re: detoast datum into the given buffer as a optimization.

it is better to try to find out why such a decision was made. On Wed, Oct 30, 2024 at 2:47 AM Andy Fan wrote: > Nikita Malakhov writes: > > > Hi! > > > > Sorry for misguiding you, I've overlooked va_rawsize with va_extinfo. > > You're right, va_rawsiz

Re: Avoid detoast overhead when possible

.postgresql.org/message-id/CAN-LCVO3GZAKVTKNwwcezoc%3D9Lq%3DkU2via-BM3MXVdOq4tD9RQ%40mail.gmail.com > > -- > Best Regards > Andy Fan > > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: detoast datum into the given buffer as a optimization.

single entry point by slightly redesigning this part? -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: detoast datum into the given buffer as a optimization.

Hi Andy, For EXPANDED attributes va_rawsize is the size of the compressed attribute, not original size. You can check toast_save_datum for that. This thread looks like the second take of the shared detoast datum patch. Have you checked my proposals in that thread? -- Regards, Nikita Malakhov

Re: Considering fractional paths in Append node

not seem incorrect to use its value for a single relation in subquery - I agree that we do not have accurate estimation at this level, but we could use the one we already have. I've also tried hard to find an example where this patch could break something, but without success. -- Nikita Malakho

Re: MergeAppend could consider sorting cheapest child path

4) (never executed) Filter: (c = d) -> Index Scan using matest1i on matest1 t2_2 (cost=0.15..76.53 rows=9 width=4) (never executed) Filter: (c = d) Planning Time: 0.278 ms Execution Time: 0.025 ms (16 rows) -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Considering fractional paths in Append node

Hi! Andy, one quick question - what do you think on using root->limit_tuples as a guidance on how many rows we have to consider in plans cost? -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Considering fractional paths in Append node

partitions in generate_orderedappend_paths() when we have a valid LIMIT value. I'm currently checking if it is working correctly in multiple cases, so 'll send it after we deal with this issue. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Considering fractional paths in Append node

Hi hackers! Sorry, I've forgot to attach the patch itself. Please check it out. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ 0001_append_limit_v1.patch Description: Binary data

Considering fractional paths in Append node

=1 width=4) (never executed) Planning Time: 0.334 ms Execution Time: 0.130 ms (11 rows) Hope this optimization could be useful. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Shared detoast Datum proposal

work, I'm looking forward to your improvements! -- 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: 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: 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

'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

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

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

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: POC: Extension for adding distributed tracing - pg_tracing

where. -- 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: [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

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: introduce dynamic shared memory registry

or re-load the extension? -- 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: 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: 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: 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: 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

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: [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: 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: 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: RFC: Pluggable TOAST

. Or should not? -- 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: 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: 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: 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, 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

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

large JSON objects. -- 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/

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

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

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

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

Re: POC: Extension for adding distributed tracing - pg_tracing

s/trace.sql:52: NOTICE: pg_tracing_planner_hook psql:/home/postgres/tests/trace.sql:52: NOTICE: pg_tracing_ExecutorStart psql:/home/postgres/tests/trace.sql:52: NOTICE: pg_tracing_ExecutorRun psql:/home/postgres/tests/trace.sql:52: NOTICE: pg_tracing_ExecutorFinish psql:/home/postgres/tests/t

Re: POC: Extension for adding distributed tracing - pg_tracing

n estimation. I've also added a query id field to span and made a table and an sql function that flushes spans to this table instead of returning set or records - it is more convenient for the maintenance to query the table. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

27;ll check the patch for the race conditions. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

s patch after review. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: POC: Extension for adding distributed tracing - pg_tracing

nsion > > Agree, something goes wrong when using Autotools (but not Meson) on > both Linux and MacOS. I didn't investigate the issue though. > > -- > Best regards, > Aleksander Alekseev > -- Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ pg-tracing-v2.patch Description: Binary data

Re: POC: Extension for adding distributed tracing - pg_tracing

Hi, Also FYI, there are build warnings because functions const char * get_span_name(const Span * span, const char *qbuffer) and const char * get_operation_name(const Span * span, const char *qbuffer) do not have default inside switch and no return outside of switch. -- Regards, Nikita Malakhov

Re: POC: Extension for adding distributed tracing - pg_tracing

library "/usr/local/pgsql/lib/pg_tracing.so": /usr/local/pgsql/lib/pg_tracing.so: undefined symbol: get_operation_name Thank you! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/ mc.log Description: Binary data

Re: POC: Extension for adding distributed tracing - pg_tracing

est.postgresql.org/44/4456/ > > -- > Best regards, > Aleksander Alekseev > > > -- Regards, -- Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Protect extension' internal tables - how?

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

Protect extension' internal tables - how?

nd of solution? Thanks in advance. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

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

Hi! Aleksander, thank you for reminding me of this patch, try to do it in a few days. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: pg_column_toast_chunk_id: a function to get a chunk ID of a TOASTed value

ists of valueid + chunk_seq. -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: Pluggable toaster

more promising in terms of performance and storage improvements. We already have a lot of changes in Pluggable TOAST that were not committed to the main GIT branch of this thread, so it seems that I have to merge them and reopen it. -- Regards, Nikita Malakhov Postgres Professional The Russian

Re: Pluggable toaster

ww.postgresql.org/message-id/flat/CAJ7c6TNAYyeMYKVkiwOZChy7UpE_CkjpYOk73gcWTXMkLkEyzw%40mail.gmail.com#59aacdde27dd61277fe7c46c61c84b2c> -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: RFI: Extending the TOAST Pointer

TOAST - extending TOAST pointer with additional structures would require review of the logical replication engine, currently it is not suitable for any custom TOAST pointers. Currently we have no final solution for problems with logical replication for custom TOAST pointers. -- Regards, Nikita Malakhov Pos

Re: RFI: Extending the TOAST Pointer

1%2B5ymNobRbOmnDRfdTonq9trZyQ%40mail.gmail.com > [2]: https://commitfest.postgresql.org/43/4296/ > > -- > Best regards, > Aleksander Alekseev > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

  1   2   3   >