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/

Re: RFI: Extending the TOAST Pointer

op using the va_tag as length indicator, but I don't > think it's currently assumed to be a length indicator anyway (see > VARSIZE_EXTERNAL(ptr)). By not using the varatt_external struct > currently in use, we could be able to get down to <18B toast pointers > as well, though I'd consider that unlikely. > > Kind regards, > > Matthias van de Meent > Neon, Inc. > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/

Re: [PATCH] Compression dictionaries for JSONB

rn to this one later. >> >> [1]: >> https://www.postgresql.org/message-id/CAJ7c6TPSvR2rKpoVX5TSXo_kMxXF%2B-SxLtrpPaMf907tX%3DnVCw%40mail.gmail.com >> >> -- >> Best regards, >> Aleksander Alekseev >> > > > -- > Regards, > > -- > Nikita Malakhov > Postgres Professional > The Russian Postgres Company > https://postgrespro.ru/ > -- 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

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/

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

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

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

JsonPath version bits

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

Re: [PATCH] Compression dictionaries for JSONB

ately (similarly to how TOAST does this)? > > Good point - should have been clearer. I meant attribute wise compression. > Like we do today, except that we would use a dictionary to increase > compression rates. > > Andres > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: [PATCH] Compression dictionaries for JSONB

; > the fact that schema may change, etc. There is a table and a > > > dictionary for this table that you refresh from time to time. Very > > > simple. > > > > You cannot "just" refresh a dictionary used once to compress an > > object, because you need it to decompress the object too. > > Right. That's what I was trying to refer to when mentioning that we might > need > to add a bit of additional information to the varlena header for datums > compressed with a dictionary. > > Greetings, > > Andres Freund > -- Regards, -- Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Pluggable toaster

ght that the most complex and questionable part would be the TOAST implementations (the Toasters) itself, and the Pluggable TOAST is just a tool to make plugging different TOAST implementations clean and simple. -- Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: Pluggable toaster

integrate the Pluggable TOAST into the vanilla, along with our advanced TOAST implementations which we plan to keep under Open Source licenses too. On Mon, Feb 6, 2023 at 1:49 PM Alvaro Herrera wrote: > On 2023-Feb-06, Nikita Malakhov wrote: > > > Currently we're busy revising th

Re: Pluggable toaster

sm needs revision at all. Currently we're busy revising the whole Pluggable TOAST API to make it available as an extension and based on hooks to minimize changes in the core. It will be available soon. > [1] https://postgr.es/m/20230203095540.zutul5vmsbmantbm@alvherre.pgsql > -- Ni

Re: Inconsistency in vacuum behavior

ll produce cache lookup ERRORs if the > relation is concurrently dropped. > > -- > Nathan Bossart > Amazon Web Services: https://aws.amazon.com > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

Re: run pgindent on a regular basis / scripted manner

itself isn't indented. > > -- > Álvaro Herrera 48°01'N 7°57'E — > https://www.EnterpriseDB.com/ > #error <https://www.EnterpriseDB.com/#error> "Operator lives in the wrong > universe" > ("Use of cookies in real-time system development", M. Gleixner, M. Mc > Guire) > > > -- Regards, Nikita Malakhov Postgres Professional https://postgrespro.ru/

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

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

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

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

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

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

  1   2   >