Re: Bug in GiST paring heap comparator

On Mon, Sep 9, 2019 at 8:32 PM Nikita Glukhov wrote: > On 08.09.2019 22:32, Alexander Korotkov wrote: > > > On Fri, Sep 6, 2019 at 5:44 PM Alexander Korotkov > > wrote: > >> I'm going to push both if no objections. > > So, pushed! > > Two years ago t

Re: [PATCH] kNN for btree

On Tue, Sep 3, 2019 at 2:19 AM Alvaro Herrera wrote: > > On 2019-Sep-03, Alexander Korotkov wrote: > > > I think patches 0001-0008 are very clear and extends our index-AM > > infrastructure in query straightforward way. I'm going to propose > > them for commit a

Re: Bug in GiST paring heap comparator

On Fri, Sep 6, 2019 at 5:44 PM Alexander Korotkov wrote: > I'm going to push both if no objections. So, pushed! -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Bug in GiST paring heap comparator

On Mon, Sep 2, 2019 at 9:28 AM Heikki Linnakangas wrote: > On 02/09/2019 07:54, Alexander Korotkov wrote: > > NULL and '(NaN,NaN)' are swapped. It happens so, because we assume > > distance to NULL to be Inf, while float8_cmp_internal() assumes NaN to > > be greater than NU

Re: [PATCH] kNN for btree

es 0001-0008 are very clear and extends our index-AM infrastructure in query straightforward way. I'm going to propose them for commit after some further polishing. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company 0004-Extract-structu

Bug in GiST paring heap comparator

ce is null" flags to GISTSearchItem. But does it worth it? ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company gist-pairing-heap-cmp-fix-1.patch Description: Binary data

Re: Yet another fast GiST build

On Fri, Aug 30, 2019 at 6:28 AM Peter Geoghegan wrote: > On Thu, Aug 29, 2019 at 8:22 PM Alexander Korotkov > wrote: > > Alternatively you can encode size in Z-value. But this increases > > dimensionality of space and decreases efficiency of join. Also, > > spatial jo

Re: Yet another fast GiST build

On Fri, Aug 30, 2019 at 2:44 PM Andrey Borodin wrote: > > 30 авг. 2019 г., в 3:47, Alexander Korotkov > написал(а): > > 1) Binary search in non-leaf pages instead of probing each key is much faster. > > > That's a neat idea, but key union breaks ordering, even for

Re: Write visibility map during CLUSTER/VACUUM FULL

On Sun, Sep 1, 2019 at 11:07 AM Alexander Korotkov wrote: > This patch have to implement its own check if tuple is allvisible. > But it appears to be possible to simplify this check assuming that all > tuples already past HeapTupleSatisfiesVacuum(), which sets hint bits. Forgot to ch

Write visibility map during CLUSTER/VACUUM FULL

. https://www.postgresql.org/message-id/flat/20131203162556.GC27105%40momjian.us#90e4a6e77d92076650dcf1d96b32ba38 -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company 0001-write-vm-during-cluster-1.patch Description: Binary data

Re: Yet another fast GiST build

On Fri, Aug 30, 2019 at 2:34 AM Peter Geoghegan wrote: > On Thu, Aug 29, 2019 at 3:48 PM Alexander Korotkov > wrote: > > > As you can see, Z-order build is on order of magnitude faster. Select > > > performance is roughly the same. Also, index is significant

Re: Yet another fast GiST build

MBR overlapping degree. This is valuable for future table AMs, which would have notion of deleting individual index tuples (for instance, zheap promises to eventually support delete-marking indexes). Eventually, we may come to the idea of B-tree indexes with user-defined additional keys in non-l

Re: Comment in ginpostinglist.c doesn't match code

uneasy about our test suite, because it doesn't cover many situations, which naturally happens only on large datasets. It's good that you've found the way to reproduce this particular case without creating enormous table. I didn't review this module yet, but +1 for idea. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Make SQL/JSON error code names match SQL standard

On Tue, Aug 20, 2019 at 11:49 AM Peter Eisentraut wrote: > I propose the attached patch to make the new SQL/JSON error code names > match the SQL standard. The existing minor differences don't seem > necessary. Thank you for noticing! +1 for pushing this -- Alexander Korotkov

Re: Support for jsonpath .datetime() method

On Tue, Aug 13, 2019 at 12:08 AM Alexander Korotkov wrote: > On Thu, Aug 1, 2019 at 1:31 PM Thomas Munro wrote: > > On Sat, Jul 27, 2019 at 2:43 AM Andrew Dunstan > > wrote: > > > On 7/23/19 6:48 PM, Nikita Glukhov wrote: > > >

Re: Improve search for missing parent downlinks in amcheck

> * > * target is the point of reference for a verification operation. > * > * Other B-Tree pages may be allocated, but those are always auxiliary (e.g., > * they are current target's child pages). Conceptually, problems are only > * ever found in the current target page (or for a p

Re: Don't like getObjectDescription results for pg_amop/pg_amproc

for builtin opclasses they always match. # select * from pg_amop amop join pg_operator op on op.oid = amop.amopopr where amop.amoplefttype != op.oprleft or amop.amoprighttype != op.oprright; (0 rows) Could we discard one pair of types from output? -- Alexander Korotkov Postgres Professional: http:

Re: Support for jsonpath .datetime() method

tance, we allow more than 4 digits to correspond to , more than 3 digits to correspond to YYY and so on. # select to_date('2019-12-31', 'YYY-MM-DD'); to_date 2019-12-31 (1 row) Links. 1. https://www.postgresql.org/message-id/d6efab15-f3a4-40d6-8ddb-6fd8f64cbc08%40postgrespro.ru -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Improve search for missing parent downlinks in amcheck

more precise missing downlink check without bloom filter. What do you think? -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company amcheck-btree-improve-missing-parent-downlinks-check-2.patch Description: Binary data

Re: SQL/JSON path: collation for comparisons, minor typos in docs

On Fri, Aug 9, 2019 at 5:27 PM Alexander Korotkov wrote: > On Thu, Aug 8, 2019 at 11:30 PM Alexander Korotkov > wrote: > > On Thu, Aug 8, 2019 at 11:53 AM Markus Winand > > wrote: > > > The patch makes my tests pass. > > > > Cool. > > > >

Re: SQL/JSON path: collation for comparisons, minor typos in docs

On Thu, Aug 8, 2019 at 11:30 PM Alexander Korotkov wrote: > On Thu, Aug 8, 2019 at 11:53 AM Markus Winand wrote: > > The patch makes my tests pass. > > Cool. > > > I wonder about a few things: > > > > - Isn’t there any code that could be

Re: SQL/JSON path: collation for comparisons, minor typos in docs

That's OK. There should be other beta testers around :) -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path: collation for comparisons, minor typos in docs

On Thu, Aug 8, 2019 at 3:05 AM Alexander Korotkov wrote: > On Thu, Aug 8, 2019 at 12:55 AM Alexander Korotkov > wrote: > > On Wed, Aug 7, 2019 at 4:11 PM Alexander Korotkov > > wrote: > > > On Wed, Aug 7, 2019 at 2:25 PM Markus Winand > > > wrote: > &g

Re: Rethinking opclass member checks and dependency strength

t; nothing else. Such an upgrade script wouldn't work in older > releases, but I think we don't generally care about that. +1 -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path: collation for comparisons, minor typos in docs

On Thu, Aug 8, 2019 at 12:55 AM Alexander Korotkov wrote: > On Wed, Aug 7, 2019 at 4:11 PM Alexander Korotkov > wrote: > > On Wed, Aug 7, 2019 at 2:25 PM Markus Winand > > wrote: > > > I was playing around with JSON path quite a bit and might have found one &

Re: SQL/JSON path: collation for comparisons, minor typos in docs

On Wed, Aug 7, 2019 at 4:11 PM Alexander Korotkov wrote: > On Wed, Aug 7, 2019 at 2:25 PM Markus Winand wrote: > > I was playing around with JSON path quite a bit and might have found one > > case where the current implementation doesn’t follow the standard. > >

Re: SQL/JSON path: collation for comparisons, minor typos in docs

h > implementation I've seen. Thank you! -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: intarray GiST index gets wrong answers for '{}' <@ anything

intarray opclasses, may be advised to rewrite their queries as following. "col <@ const" => "col <@ const AND col && const" New queries would have opclass support and handle non-empty arrays in the same way. It will be slightly slower because of evalua

Re: [PATCH] Atomic pgrename on Windows

Hi! I'd like to resume the discussion on this subject. Sorry for so long delay. On Sat, Jan 20, 2018 at 6:13 PM Magnus Hagander wrote: > On Tue, Nov 28, 2017 at 2:47 AM, Michael Paquier > wrote: >> >> On Mon, Nov 27, 2017 at 3:28 PM, Alexander Korotkov >> wrote: &g

Re: Psql patch to show access methods info

On Wed, Jul 24, 2019 at 4:59 PM Alexander Korotkov wrote: > On Wed, Jul 24, 2019 at 9:01 AM Andres Freund wrote: > > Based on a quick skim of the thread - which means I most definitely > > missed things - there's not been discussion of why we actually want to > > add this.

Re: Avoid full GIN index scan when possible

ubt it matches the documentation. I think tsvector_ops behaves so. See gin_extract_tsquery(). /* * If the query doesn't have any required positive matches (for * instance, it's something like '! foo'), we have to do a full index * scan. */ if (t

Re: Define jsonpath functions as stable

On Mon, Jul 29, 2019 at 5:55 PM Chapman Flack wrote: > On 7/29/19 10:25 AM, Alexander Korotkov wrote: > > > * like_regex predicate uses our regular expression engine, which > > deviates from standard. > > I still favor adding some element to the syntax (like a '

Re: Define jsonpath functions as stable

for the explanation. Given that there is no need to mark existing json_path_*() functions as stable. We can just advise users to rebuild their indexes if we have incompatible changes. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Define jsonpath functions as stable

think once we sure enough that we know immutable subset of jsonpath, we may define immutable functions for its evaluation. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company switch_jsonpath_functions_to_stable.patch Description: Binary data

Re: Psql patch to show access methods info

ced users using pl/something, I've faced that several times. > Adding stuff to psql isn't free. It adds clutter to psql's help output, > the commands need to be maintained (including cross-version code). Sure. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Psql patch to show access methods info

Hi! On Wed, Jul 24, 2019 at 9:00 AM Andres Freund wrote: > On 2019-07-23 01:57:29 +0300, Alexander Korotkov wrote: > > It was always scary there is no way in psql to see am/opclass/opfamily > > information rather than query catalog directly. > > What does make that scary?

Re: Support for jsonpath .datetime() method

e() and CAST(... FORMAT ...). I propose to leave this functions as is (maybe add new patterns), but introduce another datetime parsing mode, which would fit to the standard. Opinions? -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Psql patch to show access methods info

and output formats are not well discussed yet. But we're pretty earlier in 13 release cycle. So, we will have time to work out a criticism if any. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Psql patch to show access methods info

On Mon, Jul 22, 2019 at 6:29 AM Alvaro Herrera wrote: > On 2019-Jul-21, Alexander Korotkov wrote: > > I've one note. Behavior of "\dA" and "\dA pattern" look > > counter-intuitive to me. I would rather expect that "\dA pattern" > > would just

Re: Psql patch to show access methods info

ather expect that "\dA pattern" would just filter results of "\dA", but it displays different information. I suggest rename displaying access method properties from "\dA pattern" to different. And leave "\dA pattern" just filter results of "\dA". -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [PATCH v2] Introduce spgist quadtree @<(point,circle) operator

on the example. Imagine centroids (0,1) and (1,0). Square (0,0)-(1,1) is intersection of quadrant 2 of (0,1) and quadrant 4 of (1,0). And then imagine circle with center in (2,2) of radius 1. It intersects with both quadrants, but doesn't intersect with square. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path issues/questions

s.html -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path issues/questions

On Thu, Jul 18, 2019 at 5:08 PM Thom Brown wrote: > On Tue, 16 Jul 2019 at 19:44, Alexander Korotkov > wrote: > > > > On Tue, Jul 16, 2019 at 9:22 PM Thom Brown wrote: > > > Now I'm looking at the @? and @@ operators, and getting a bit > > > confused. This

Re: fix for BUG #3720: wrong results at using ltree

e what do these checks do. Code around is uncommented and puzzled. But could we guarantee the same invariant on the stage of ltree/lquery parsing? -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path issues/questions

On Thu, Jul 11, 2019 at 5:10 PM Thom Brown wrote: > On Wed, 10 Jul 2019 at 05:58, Alexander Korotkov > wrote: > > > > On Mon, Jul 8, 2019 at 12:30 AM Alexander Korotkov > > wrote: > > > On Thu, Jul 4, 2019 at 4:38 PM Liudmila Mantrova > > > wrote: >

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

uplication off looks enough for me. Regarding bitmap indexes itself, I think our BRIN could provide them. However, it would be useful to have opclass parameters to make them tunable. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

reat an insertion of a tuple with > NULLs into a unique index as if it wasn't even a unique index -- see > the "checkingunique" optimization at the beginning of _bt_doinsert(). > Having many NULL values in a unique index is probably fairly common. I think unique indexes may benefit from deduplication not only because of NULL values. Non-HOT updates produce duplicates of non-NULL values in unique indexes. And those duplicates can take significant space. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path issues/questions

On Mon, Jul 8, 2019 at 12:30 AM Alexander Korotkov wrote: > On Thu, Jul 4, 2019 at 4:38 PM Liudmila Mantrova > wrote: > > Thank you! > > > > I think we can make this sentence even shorter, the fix is attached: > > > > "To refer to a JSON element

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

aken over patch ownership, should I move my > name from reviewer to author in the CF app? And can there be two > authors listed there? Sure, you're co-author of this patch. Two or more authors could be listed at CF app, you can find a lot of examples on the list. -- Alexander Ko

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

so, I'd like to note that with our default_statistics_target == 100, non MCV values are not so rare. So, I'm +1 for taking histogram into account. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Add missing operator <->(box, point)

On Mon, Jul 8, 2019 at 11:39 PM Nikita Glukhov wrote: > On 08.07.2019 18:22, Alexander Korotkov wrote: > For me it doesn't look worth having two distinct functions > gist_box_distance_helper() and gist_bbox_distance(). What about > having just one and leave responsibility for

Re: [PATCH] kNN for btree

se cycle, but let's start with just simple case. I also think we can evade replacing amcanorderbyop flag with method, but introduce just new boolean flag indicating knn supports only first column. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Add missing operator <->(box, point)

fnoid == F_DIST_POLYP; So, it seems to be fix of oversight in 2a6368343ff4. But assuming fixing this requires catalog changes, we shouldn't backpatch this. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path issues/questions

looks good to me. Attached revision of patch contains commit message. I'm going to commit this on no objections. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company 0004-clarify-jsonpath-docs-5.patch Description: Binary data

Re: SQL/JSON path issues/questions

y which to filter the result." Could we phrase this as following? "In order to filter the result by values lying on lower nesting level, @ operator can be followed by one or more accessor operators." -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Add missing operator <->(box, point)

On the other hand, are we already going to limit oid consumption? -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] Custom compression methods

On Mon, Jul 1, 2019 at 5:51 PM Alvaro Herrera wrote: > On 2019-Jul-01, Alexander Korotkov wrote: > > > As I get we're currently need to make high-level decision of whether > > we need this [1]. I was going to bring this topic up at last PGCon, > > but I didn't manage t

Re: [HACKERS] Custom compression methods

/www.postgresql.org/message-id/20190216054526.zss2cufdxfeudr4i%40alap3.anarazel.de -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Avoid full GIN index scan when possible

ly used to scan the index. It some cases it may > > not be possible (e.g. in cases when the decision is done at runtime, not > > while planning the query), but it'd be nice to show it when possible. > > Maybe we could somehow add some runtime information about ignored > quals, similar to the "never executed" information for loops? +1, This sounds reasonable for me. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Avoid full GIN index scan when possible

tmap Index Scan' doesn't vary much whether we execute GIN_SEARCH_MODE_ALL or not. The only difference is for multicolumn index, GIN_SEARCH_MODE_ALL allows to exclude NULL on one column, when normal scan is performed on another column. And we can take it into account in gincostestimate(). -- Ale

Re: Avoid full GIN index scan when possible

ppen when two-columns index have GIN_SEARCH_MODE_DEFAULT scan on first column and GIN_SEARCH_MODE_ALL on second? I think even if triconsistent() for second column returns GIN_TRUE, we still need to recheck to verify second columns is not NULL. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path issues/questions

On Fri, Jun 28, 2019 at 9:01 AM Oleg Bartunov wrote: > On Fri, Jun 28, 2019 at 8:10 AM Alvaro Herrera > wrote: > > > > On 2019-Jun-28, Alexander Korotkov wrote: > > > > > On Tue, Jun 25, 2019 at 6:38 PM Liudmila Mantrova > > > wrote: > > >

Re: SQL/JSON path issues/questions

e introduce the notion of just filter. What is it? Could we make it without introduction of new notion? ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path issues/questions

On Thu, Jun 27, 2019 at 4:57 PM Thom Brown wrote: > On Wed, 19 Jun 2019 at 20:04, Alexander Korotkov > wrote: > > On Wed, Jun 19, 2019 at 7:07 PM Thom Brown wrote: > > > On Thu, 13 Jun 2019 at 14:59, Thom Brown wrote: > > > Also, this example doesn't work: >

Re: Usage of epoch in txid_current

On Mon, Jun 24, 2019 at 8:43 PM Alvaro Herrera wrote: > > On 2019-Jun-22, Alexander Korotkov wrote: > > > 2. Also introduce FullMultixactId, and apply to MultixactId the > > similar change as #1. > > 3. Change SLRU on-disk format to handle 64-bit xids and multixacts.

Re: Usage of epoch in txid_current

Hi! On Mon, Jun 24, 2019 at 6:27 PM Andres Freund wrote: > On June 24, 2019 8:19:13 AM PDT, Robert Haas wrote: > >On Fri, Jun 21, 2019 at 7:01 PM Alexander Korotkov > > wrote: > >> On Thu, Mar 28, 2019 at 8:30 AM Thomas Munro > >wrote: > >> > Than

Re: GiST "choose subtree" support function to inline penalty

mplement this strategy in correct way. However, this use case is kind of opposite to Darafei's one, because it should make choosing subtree slower (but better). -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Usage of epoch in txid_current

having 64-bit xids in core. Especially assuming we now have pluggable table AMs, and it would be ridiculous to spear limitation of 32-bit xids to new table AMs. Links 1. https://wiki.postgresql.org/wiki/FOSDEM/PGDay_2018_Developer_Meeting ------ Alexander Korotkov Postgres Profe

Re: SQL/JSON path issues/questions

On Wed, Jun 19, 2019 at 10:14 PM Alexander Korotkov wrote: > > While I have no objections to the proposed fixes, I think we can further > > improve patch 0003 and the text it refers to. > > In attempt to clarify jsonpath docs and address the concern that ? is > > hard to t

Re: SQL/JSON path issues/questions

> Please see both of them attached. Thank you for your editing. I'm going to commit them as well. But I'm going to commit your changes separately from 0003 I've posted before. Because 0003 fixes factual error, while you're proposing set of grammar/style fixes. -- Alexander Korotkov Postgr

Re: SQL/JSON path issues/questions

es given > in 9.15. JSON Functions, Operators, and Expressions aren't all > functional. Some example JSON is provided, followed by example > jsonpath queries which could be used against it. These will produce > results for the reader wishing to test them out until this example: > > '$.track.segments[*].HR ? (@ > 130)' > > This is because there is no HR value greater than 130. May I propose > setting this and all similar examples to (@ > 120) instead? Makes sense to me. > Also, this example doesn't work: > > '$.track ? (@.segments[*] ? (@.HR > 130)).segments.size()' > > This gives me: > > psql: ERROR: syntax error, unexpected $end at end of jsonpath input > LINE 13: }','$.track ? (@.segments[*]'); > ^ Perhaps it should be following: '$.track ? (exists(@.segments[*] ? (@.HR > 130))).segments.size()' -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path issues/questions

. > > Can I suggest that, rather than using "question mark", we use the "?" > symbol, or provide a syntax structure which shows something like: > > ? > > This not only makes this key information clearer and more prominent, > but it also makes the "?" symbol searchable in a browser for anyone > wanting to find out what that symbol is doing. Sounds good for me. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path issues/questions

> > I get an error when I run this query: > > > > > > postgres=# SELECT jsonb_path_query('[2]', '2 + $[1]'); > > > psql: ERROR: right operand of jsonpath operator + is not a single > > > numeric value > > > > > > While I k

Re: SQL/JSON path issues/questions

constitute and array. Should we say something like "There are %d values"? Also, probably we should display the type of single element if it's not numeric. jsonb_path_match() also throws ERRCODE_SINGLETON_JSON_ITEM_REQUIRED, should we add similar errdetail() there? --

Re: SQL/JSON path issues/questions

g/docs/devel/functions-json.html#FUNCTIONS-SQLJSON-PATH -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: SQL/JSON path issues/questions

of how > to fix it for the present.. I'm also not sure. Need further thinking about it. > > Can't use nested arrays with jsonpath > > == > > > > I encounter an error in this scenario: > > > > postgres=# select jsonb_path_query('[1, 2, 1, [1,2], 3]

Hash join explain is broken

ed by Nikita Glukhov. I didn't investigate this case further yet. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: doc: pg_trgm missing description for GUC "pg_trgm.strict_word_similarity_threshold"

On Sat, Jun 8, 2019 at 8:17 PM Alexander Korotkov wrote: > On Fri, Jun 7, 2019 at 6:02 PM Ian Barwick > wrote: > > On 6/7/19 9:00 PM, Michael Paquier wrote: > > > On Fri, Jun 07, 2019 at 03:44:14PM +0900, Masahiko Sawada wrote: > > > Or is that not worth bothe

Re: doc: pg_trgm missing description for GUC "pg_trgm.strict_word_similarity_threshold"

ons in back branches. So, I'm +1 for backpatching. I'm going to commit all 3 patches (documentation, GUC description, documentation indentation) on no objections. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

s. If we put functionality of CLUSTER and VACUUM FULL to ALTER TABLE, and put functionality of REINDEX to ALTER INDEX, then CLUSTER, VACUUM FULL and REINDEX would be just syntax sugar. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [PROPOSAL] Drop orphan temp tables in single-mode

single-user mode? Do we need it in multi-user mode too? BTW, does this patch checks that temporary table is really orphan? AFAICS, user may define some temporary tables in single-user mode before running VACUUM. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: New committer: David Rowley

d Rowley has joined the ranks of PostgreSQL > committers. > > Congratulations to David, may the buildfarm be gentle to him, and his first > revert far away! +1 Congratulations to David! Very much deserved! -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: PostgreSQL 12 Beta 1 press release draft

orate changes > prior to the release. I suggest renaming "Most-common Value Statistics" to "Multicolumn Most-common Value Statistics". Looking on current title one may think we didn't support MCV statistics at all, but we did support single-column case for a long time. -- Al

Re: PG 12 draft release notes

On Tue, May 21, 2019 at 3:49 AM Peter Geoghegan wrote: > On Mon, May 20, 2019 at 3:17 PM Andres Freund wrote: > > > > > > > > Improve speed of btree index insertions (Peter Geoghegan, > > Alexander Korotkov) > > > &g

Re: jsonpath

On Fri, May 17, 2019 at 6:50 AM Alexander Korotkov wrote: > Couple patches improving jsonpath docs are attached. The first one > documents nesting level filter for .** accessor. The second adds to > documentation of jsonpath array subsciption usage of expressions and > multiple

Re: jsonpath

Couple patches improving jsonpath docs are attached. The first one documents nesting level filter for .** accessor. The second adds to documentation of jsonpath array subsciption usage of expressions and multiple slice ranges. I'm going to push both patches if no objections. -- Alexander

Re: Re: SQL/JSON: functions

t;b3": "8z"}]}}'::json, '$.c1.c2[0... > ^ > DETAIL: syntax error, unexpected ':', expecting ',' or ']' at or near ":" There is no color syntax from array slicing in jsonpath. Instead of "[0:]" one should write "[0 to last]". See documentation https://www.postgresql.org/docs/devel/datatype-json.html#TYPE-JSONPATH-ACCESSORS -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: jsonpath

On Tue, May 7, 2019 at 5:35 PM Tom Lane wrote: > Alexander Korotkov writes: > > Attached patchset contains revised commit messages. I'm going to > > commit this on no objections. > > Sorry for slow response --- I was tied up with release preparations. > > The

Re: jsonpath

On Tue, Apr 30, 2019 at 1:20 AM Alexander Korotkov wrote: > On Mon, Apr 29, 2019 at 6:11 PM Tom Lane wrote: > > Alexander Korotkov writes: > > > [ jsonpath-errors-improve-3.patch ] > > > > This is getting better, but IMO it's still a bit too willing to use &

Re: to_timestamp docs

','FXMON_MON_MON'); > ERROR: invalid value " J" for "MON" > DETAIL: The given value did not match any of the allowed values for this > field. Actually, FX takes effect on subsequent format patterns. This is not documented, but it copycats Oracle behavior. Sure, normally FX should be specified as the first item. We could document current behavior or restrict specifying FX not as first item. This is also not new in 12, so documenting current behavior is better for compatibility. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: jsonpath

On Mon, Apr 29, 2019 at 6:11 PM Tom Lane wrote: > Alexander Korotkov writes: > > [ jsonpath-errors-improve-3.patch ] > > This is getting better, but IMO it's still a bit too willing to use > a boilerplate primary error message plus errdetail. I do not think > that is projec

Re: jsonpath

On Thu, Apr 25, 2019 at 10:29 PM Tom Lane wrote: > Alexander Korotkov writes: > > I'm going to commit these adjustments if no objections. > > Sorry for not getting to this sooner. Looking quickly at the v2 patch, > it seems like you didn't entirely take to heart the

Re: Improve search for missing parent downlinks in amcheck

On Sun, Apr 28, 2019 at 4:36 AM Peter Geoghegan wrote: > On Sat, Apr 27, 2019 at 5:13 PM Alexander Korotkov > wrote: > > Yes, increasing of Bloom filter size also helps. But my intention was > > to make non-lossy check here. > > Why is that your intention? Do you want

Re: Improve search for missing parent downlinks in amcheck

On Tue, Apr 16, 2019 at 10:00 PM Peter Geoghegan wrote: > > On Mon, Apr 15, 2019 at 7:30 PM Alexander Korotkov > wrote: > > Currently we amcheck supports lossy checking for missing parent > > downlinks. It collects bitmap of downlink hashes and use it to check > > su

Re: Improve search for missing parent downlinks in amcheck

ng situation? A / \ B <-> C <-> D Here A has downlinks to B and D, which downlink to C is missing, while B, C and D are correctly connected with leftlinks and rightlinks. I can see "rootdescend" calls _bt_search(), which would just step right from C to

Re: jsonpath

On Wed, Apr 24, 2019 at 9:03 PM Alexander Korotkov wrote: > On Mon, Apr 22, 2019 at 1:39 AM Tom Lane wrote: > > Alexander Korotkov writes: > > >> On Wed, Apr 17, 2019 at 8:43 PM Tom Lane wrote: > > >>> Yeah, I'd noticed that one too :-(. I think the whole

Re: Regression test coverage of GiST index build is awful

n near 100% coverage for what it's costing in runtime. I don't think there is any idea behind this. Seems to be just oversight. Do you like me to write a patch improving coverage here? -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: jsonpath

On Mon, Apr 22, 2019 at 1:39 AM Tom Lane wrote: > Alexander Korotkov writes: > >> On Wed, Apr 17, 2019 at 8:43 PM Tom Lane wrote: > >>> Yeah, I'd noticed that one too :-(. I think the whole jsonpath patch > >>> needs a sweep to bring its error messages into

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

On Thu, Nov 29, 2018 at 3:44 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On Fri, Aug 24, 2018 at 5:53 PM Alexander Korotkov > > wrote: > > > > Given I've no feedback on this idea yet, I'll try to implement a PoC > > patch for that. It doesn't l

Re: jsonpath

Hi! Thank you for your review! On Mon, Apr 22, 2019 at 1:39 AM Tom Lane wrote: > Alexander Korotkov writes: > RETURN_ERROR(ereport(ERROR, > (errcode(ERRCODE_JSON_ARRAY_NOT_FOUND), >

<    3   4   5   6   7   8   9   10   11   12   >