Re: Correct SQLSTATE for ENOMEM in file access

On Fri, Feb 2, 2024 at 8:12 PM Tom Lane wrote: > Hmm, do you think this is actually reachable? AFAIK we should only be > calling errcode_for_file_access() after functions that are unlikely to > report ENOMEM. It's reachable, that's how I noticed. I'm seeing logs like "XX000: could not load

Correct SQLSTATE for ENOMEM in file access

this. --- Alexander Kuzmenkov Timescale diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c index 2c7a20e3d3..9860bf079a 100644 --- a/src/backend/utils/error/elog.c +++ b/src/backend/utils/error/elog.c @@ -922,6 +922,10 @@ errcode_for_file_access(void) edata->sqlerrc

Re: Incorrect cost for MergeAppend

On Wed, Jan 31, 2024 at 9:49 PM David Rowley wrote: > Pushed to master. > > Thanks for the report and the fix, Alexander. Thank you!

Re: Incorrect cost for MergeAppend

On Wed, Jan 31, 2024 at 1:33 PM Alexander Kuzmenkov wrote: > I'd be happy to see this backpatched. What kind of regressions are we > worried about? I'd say partition-wise sort + merge should be faster > than append + sort for reasonably sized tables. That's basically what > tuplesort

Re: Incorrect cost for MergeAppend

I'd be happy to see this backpatched. What kind of regressions are we worried about? I'd say partition-wise sort + merge should be faster than append + sort for reasonably sized tables. That's basically what tuplesort does inside. Moreso, this can enable index scans on partitions, which is an even

Re: Incorrect cost for MergeAppend

On Tue, Jan 30, 2024 at 1:20 PM David Rowley wrote: > You should likely focus on trying to find a test that does not require > making 2 tables with 10k rows. Is 1k smallint OK? It should fit in one page. Still reproduces the error, and the entire test case runs in under 10 ms. diff --git

Re: Incorrect cost for MergeAppend

Here is a small patch that reproduces the problem on two tables with inheritance, and fixes it. I'll add it to the Commitfest. On Tue, Jan 30, 2024 at 8:20 AM Ashutosh Bapat wrote: > > On Mon, Jan 29, 2024 at 6:11 PM Alexander Kuzmenkov > wrote: > > > > Hello h

Incorrect cost for MergeAppend

e been studying involve a third-party extension, but the code looks incorrect so I thought I should ask. Here is a link to this code on GitHub: https://github.com/postgres/postgres/blob/6a1ea02c491d16474a6214603dce40b5b122d4d1/src/backend/optimizer/util/pathnode.c#L1469-L1477 --- Alexander Kuzmenkov Timescale

Re: [RFC] ASOF Join

ies and silently falling back to an inefficient plan for cryptic reasons. -- Alexander Kuzmenkov Timescale

[RFC] ASOF Join

ed loop plan could work if we have a (timestamp, equi-keys) btree index. Prototype Implementation For a prototype, I'd go with #3 "merge-something with a hash table of most recent rows for equi-keys", because it works for big tables and can reuse the physical data ordering. I'll be glad to hear your thoughts on this. -- Alexander Kuzmenkov Timescale

preserve timestamps when installing headers

ementioned install flag, it allows a developer to hack on both postgres and a third-party extension at the same time, without the unneeded recompilation. -- Alexander Kuzmenkov Timescale diff --git a/src/include/Makefile b/src/include/Makefile index 5f257a958c..27242ff910 100644 --- a/src/includ

Re: Table AM and DROP TABLE [ Was: Table AM and DDLs]

itself pluggable: https://www.postgresql.org/message-id/flat/1dc080496f58ce5375778baed0c0fbcc%40postgrespro.ru#502a1278ad8fce6ae85c08b4806c2289 -- Alexander Kuzmenkov https://www.timescale.com/

Re: Removing unneeded self joins

On 3/25/19 18:13, Alexander Kuzmenkov wrote: Please see the attached v15. I won't be able to continue working on this because I'm changing jobs. My colleague Arseny Sher is probably going to take over. Here is a v16 that is a rebased v12, plus renames from v15, plus a couple of bug fixes

Re: Removing unneeded self joins

I noticed you lost a couple of test cases in v14, so I added them back. I also added a case where your implementation returns a different number of rows compared to vanilla: select * from sl t1, sl t2 where t1.a = t2.a and t1.b = 1; Please see the attached v15. -- Alexander Kuzmenkov

Re: Removing unneeded self joins

at least one join clause that equates the same inner and outer column? Why is one join clause enough? -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Removing unneeded self joins

share of problems. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company >From c40b4b59df27e24c2238f422d5c6fde6fe1a91d3 Mon Sep 17 00:00:00 2001 From: Alexander Kuzmenkov Date: Fri, 22 Mar 2019 17:25:01 +0300 Subject: [PATCH v13] Remove uni

Re: Optimze usage of immutable functions as relation

that does this, and transforms RTE_FUCTION that was reduced to a single Const into an RTE_RESULT. Not sure it does everything correctly, but some basic cases work. In particular, I don't understand whether it needs any handling of "append relations". -- Alexander Kuzmenkov Postgres Pr

Re: Removing unneeded self joins

of the patch. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company >From d3bb27a26919441df1c31645ff39655c124e5ae6 Mon Sep 17 00:00:00 2001 From: Alexander Kuzmenkov Date: Wed, 20 Mar 2019 15:15:33 +0300 Subject: [PATCH v12] Remove unique self jo

Re: Optimze usage of immutable functions as relation

On 3/5/19 20:22, David Steele wrote: I'll close this on March 8th if there is no new patch. This is taking longer than expected. I'll move it to the next commitfest and continue working on the patch. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian

Re: Optimze usage of immutable functions as relation

On 2/18/19 03:20, Tom Lane wrote: The dummy-relation stuff I referred to has now been merged, so there's really no good reason not to revise the patch along that line. I'll try to post the revised implementation soon. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com

Re: Removing unneeded self joins

al and stored in a parallel list. Now I changed it to UniqueRelInfo which always has outerrelids and optionally the unique index. I also fixed a bug with not updating the references in HAVING clause. New version is attached. -- Alexander Kuzmenkov Postgres Professional: http://www.po

Re: First-draft release notes for next week's releases

El 9/2/19 a las 4:19, Tom Lane escribió: Please send comments/corrections by Sunday. +  tuple deletion WAL record (Stas Kelvish) -- a typo in his surname, should be Kelvich. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Redundant filter in index scan with a bool column

. I considered something like redundancy_tag, but some places actually use the fact that it points to the generating EC, so I don't like this name either. What do you think? -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company >F

Re: Removing unneeded self joins

Here is a rebased version with some bugfixes. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company >From 5ad486a16346a0141146c488dac74331da777af8 Mon Sep 17 00:00:00 2001 From: Alexander Kuzmenkov Date: Mon, 17 Dec 2018 17:47:18 +0300 Subj

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

On 11/29/18 22:13, Tom Lane wrote: Ooops, I had not seen this before sending v4 patch. Doesn't seem worth posting a v5 for, but I'll be sure to fix it. Thanks for updating, v4 looks good to me. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

Oh, one more thing: I see a warning without --enable-cassert in create_resultscan_plan, because rte is only used in an Assert. src/backend/optimizer/plan/createplan.c:3457:17: warning: variable ‘rte’ set but not used [-Wunused-but-set-variable]   RangeTblEntry *rte; -- Alexander Kuzmenkov

Re: "SELECT ... FROM DUAL" is not quite as silly as it appears

or the aforementioned simplification of JOIN_LEFT and JOIN_RIGHT, but it's probably not worth adding a special test. I checked these cases manually and they work OK. I also repeated the benchmark with trivial select and can confirm that there is no change in performance. -- Alexander Kuzmenkov Postgr

Re: Implement predicate propagation for non-equivalence clauses

 */     if (new_rinfo->mergeopfamilies)         initialize_mergeclause_eclasses(root, new_rinfo); * It's not an equality clause, so it is not going to be mergejoinable nor hashjoinable and we can skip these checks. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Index Skip Scan

y Scan Backward using ta on t  (cost=0.42..1.00 rows=478385 width=4) Scan mode: Skip scan (3 rows) # select count(*) from (select distinct a from t order by a desc) d;  count  502733 -- should be 500k (1 row) -- Alexander Kuzmenkov Postgres Professional: http://www.postgresp

Re: [HACKERS] PoC: full merge join on comparison clause

this patch as rejected then. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Removing unneeded self joins

El 08/11/18 a las 08:59, David Rowley escribió: On 19 October 2018 at 01:47, Alexander Kuzmenkov wrote: Here is a version that compiles. I had a quick read through this and I think its missing about a 1-page comment section detailing when we can and when we cannot remove these self joins

Re: Index Skip Scan

On 9/27/18 16:59, Jesper Pedersen wrote: Hi Dmitry, On 9/15/18 3:52 PM, Dmitry Dolgov wrote: On Thu, 13 Sep 2018 at 21:36, Alexander Kuzmenkov wrote: El 13/09/18 a las 18:39, Jesper Pedersen escribió: I think we can improve this, and the skip scan can be strictly faster than index scan

Re: Uninterruptible long planning of a query with too many WHERE clauses

for the client. In the long run, I think we don't have to add them, because normally, planning a query is relatively fast, and unexpected slowdowns like this one can still happen in places where we don't process interrupts. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com

Re: Removing unneeded self joins

Here is a version that compiles. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c index 3bb91c9..62d46a1 100644 --- a/src/backend/nodes/equalfuncs.c +++ b/src

Re: Removing unneeded self joins

Here is a rebased version of the patch. It includes some fixes after an off-list review by Konstantin Knizhnik. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/nodes/equalfuncs.c b/src/backend/nodes/equalfuncs.c

buildfarm and git pull

# recursively delete all unversioned and ignored files Do you think this approach is correct or am I missing something? -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Index Skip Scan

in BTScanOpaqueData. I'll take a look after my upcoming vacation; feel free to contribute those changes in the meantime of course. I probably won't be able to contribute the changes, but I'll try to review them. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian

Re: Index Skip Scan

can just use it always and not worry about our unreliable statistics. What do you think? -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company test-skip.sql Description: application/sql

Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused

The last version looked OK, so I'm marking this patch as ready for committer in the commitfest app. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Performance improvements for src/port/snprintf.c

han we are with floats, but it uses its own algorithm for that. It is also faster with decimals, probably because it uses a two-digit lookup table, not one-digit like we do. Unfortunately it doesn't support dollars. 1. https://github.com/nothings/stb/blob/master/stb_sprintf.h -- Alexander Kuzme

Re: Enable using IS NOT DISTINCT FROM in hash and merge joins

s. I had to do this to support merge joins on inequality clauses, you can take a look at this thread if you wish: https://www.postgresql.org/message-id/flat/b31e1a2d-5ed2-cbca-649e-136f1a7c4c31%40postgrespro.ru -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian

Re: Reopen logfile on SIGHUP

https://www.freebsd.org/cgi/man.cgi?query=sigaction=0=0=FreeBSD+4.0-RELEASE=default=html Debian 4.0, which was released in 2007 and had a 2.6 kernel, also claims to have a signal-safe unlink(): https://www.freebsd.org/cgi/man.cgi?query=signal=0=0=Debian+4.0.9=default=html -- Alexander Kuzmenkov

Re: Reopen logfile on SIGHUP

I think the latest v4 patch addresses the concerns raised upthread. I'm marking the commitfest entry as RFC. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Removing unneeded self joins

for both sides have the same type. I added the code to check for that. You can't declare a variable here in C89. Fixed. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company >From a72a36567b8f0855f223196aca31dd051bd0d7e4 Mon Sep 17 00:00:00 2001 F

Re: [HACKERS] PoC: full merge join on comparison clause

and the first column matches the join condition. But inside each group, for some rows the second column doesn't match. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company >From c817ac1f93b83bcf43afac4af2dbaed37403a4a2 Mon Sep 17 00:00:00 2001 Fro

Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused

clauses. Please see the attached v6. Otherwise I think the patch is good. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company >From e6006da62d7d4c0c54750260e864e52e93e2dba9 Mon Sep 17 00:00:00 2001 From: Daniel Gustafsson Date: Tue, 12 Jun 2018 14

Re: Removing unneeded self joins

meaningful changes are in analyzejoins.c anyway. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company >From 2f2be5d5efa0fcef38a0d6dd1225c73a377f88b8 Mon Sep 17 00:00:00 2001 From: Alexander Kuzmenkov Date: Wed, 13 Jun 2018 20:56:03 +0300 Subj

Re: [HACKERS] PoC: full merge join on comparison clause

outer_pathkeys_for_merge() chooses the order of pathkeys using some heuristics, and then find_mergeclauses_for_outer_pathkeys() reorders the clauses accordingly. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company >From 6171be01494422a3cad5b5cf

Re: [HACKERS] PoC: full merge join on comparison clause

comments now, will post the updated version this week. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Generating partitioning tuple conversion maps faster

credited as a reviewer. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Generating partitioning tuple conversion maps faster

v4 1  414 416 408 2  259 409 404 3  263 400 405 4  417 416 404 5  118 311 305 6  85  280 303 -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company >F

Re: Generating partitioning tuple conversion maps faster

probably going to be even faster, because it will only require one catalog access for each index shift. Now it looks like it goes to catalog for every column after the dropped one. What about convert_tuples_by_name_map, do you plan to switch it to catalog lookups as well? -- Alexander Kuzmenkov

Re: Generating partitioning tuple conversion maps faster

through this if we had a hash table that is easy to use, or perhaps string interning in catcache. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/access/common/tupconvert.c b/src/backend/access/common/tupconvert.c index

Re: Avoid extra Sort nodes between WindowAggs when sorting can be reused

en whether it is a right thing to do. What do you think? -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Removing unneeded self joins

joins. I didn't time the join removal itself, because it wins quite some time by allowing to plan one relation and one join less. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company >From ad5f5b59265762b3674068ee3656baec3ec66b70 Mon Sep 17 00:00

Re: PATCH: backtraces for error messages

/interesting/worth pursuing? This would be a great thing to have. I often need to add stack traces to the logs, and for now I just link with libunwind and add some ad-hoc function to grab the traces. Having libunwind support in core would make this simpler. -- Alexander Kuzmenkov Postgres

Re: Removing unneeded self joins

David, Many thanks for the detailed explanation. I'll try to code it up and measure how much overhead it introduces. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Removing unneeded self joins

-jsycajhrdvjqnn7m2slh1wlh-_z2...@mail.gmail.com -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c index 477b9f7..334793c 100644 --- a/src/backend/optimizer

Re: Reopen logfile on SIGHUP

Here is a documentation update from Liudmila Mantrova. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 4a68ec3..5bd7b45 100644 --- a/doc/src/sgml

Re: Reopen logfile on SIGHUP

On 04/25/2018 05:57 PM, Sergei Kornilov wrote: Attached file is empty. My bad, here is the correct file. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index

Re: Reopen logfile on SIGHUP

of messages and how to fix it. I also removed the forgotten declaration of CheckLogrotateSignal from xlog.h. The updated patch is attached. We should probably have a commitfest entry for this, so here it is: https://commitfest.postgresql.org/18/1622/ -- Alexander Kuzmenkov Postgres

Re: Reopen logfile on SIGHUP

tateSignal to postmaster.c, since it has no reason to be in xlog.c - added some documentation I had from my older patch Other than that, it looks good to me. The updated patch is attached. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff -

Re: [patch] pg_attribute.attndims turns to 0 when 'create table like/as'

with it? [1] https://www.postgresql.org/message-id/3792.1485959113%40sss.pgh.pa.us -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Reopen logfile on SIGHUP

file name, the log file is always open, so this method doesn't work. I'm not sure how to make this work reliably. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index

Re: Reopen logfile on SIGHUP

on SIGHUP under some conditions, so we can just change this to unconditional rotation. Probably some people wouldn't want their logs to be rotated on SIGHUP, so we could also add a GUC to control this. Please see the attached patch. -- Alexander Kuzmenkov Postgres Professional: http

Re: [HACKERS] [PATCH] Incremental sort

. enable_sort should act as a cost-based soft disable for both incremental and normal sort. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out b/contrib/postgres_fdw/expected

Re: [HACKERS] [PATCH] Incremental sort

or just return false by default. That's all I have for today; tomorrow I'll continue with reviewing the planner part of the patch. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/contrib/postgres_fdw/expected/postgres_fdw.out

Re: IndexJoin memory problem using spgist and boxes

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested The updated version looks good to me. make installcheck under valgrind

Re: [HACKERS] PoC: full merge join on comparison clause

On 05.03.2018 08:30, Ashutosh Bapat wrote: But creating such patches using git format-patch (with -v as some suggest) really helps in general. Thanks for the advice. I heard about this workflow, but never used it myself. Perhaps it's time to try it. -- Alexander Kuzmenkov Postgres

Re: IndexJoin memory problem using spgist and boxes

. The allocations are not very apparent in the code, so it's easy to miss something. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: IndexJoin memory problem using spgist and boxes

-0o7CwsU0UCnAshOtpDR8cSpSjy0g%40mail.gmail.com#capqrbe5vtgwcgroc91bmu-0o7cwsu0ucnashotpdr8cspsj...@mail.gmail.com Also, this link doesn't open for me. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: heap_lock_updated_tuple_rec can leak a buffer refcount

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested Looks like a leak indeed, the fix seems right.

Re: Rangejoin rebased

that it knows which pathkeys are compatible to which range join clauses. About the patch, do I understand it right that you are working on the next version now? -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

to fix this. I think we could average the number of tuples, not the densities. The attached patch demonstrates what I mean. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company *** /tmp/DqhRGF_vacuum.c 2018-03-02 18:43:54.448046402 +0300 --- src

Re: [HACKERS] PoC: full merge join on comparison clause

On 22.02.2018 21:42, Alexander Kuzmenkov wrote: Some basic joins work, but I couldn't properly test all the corner cases with different orderings, because they depend on a bug in vanilla merge joins [1]. The bug was fixed, so here is the rebased patch. The planner part of the patch

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

, the results of analyze and vacuum were used directly, without averaging. What I am suggesting is to use a different way of averaging, not to remove it. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company analyze.tex.pdf Description: Adobe PDF

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

on analyze/vacuum, and then apply moving average to it. The calculations would be shorter, too. What do you think? -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

couldn't think of one yet. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: ERROR: left and right pathkeys do not match in mergejoin

. In create_mergejoin_plan:     * implied inner ordering is then "ORDER BY x, y, x", but the pathkey     * drops the second sort by x as redundant, and this code must cope. -- should this read "the pathkey machinery drops"? -- Alexander Kuzmenkov Postgres Professional: http:/

Re: ERROR: left and right pathkeys do not match in mergejoin

r relation. Also, we should take care not to create such combinations in select_outer_pathkeys_for_merge, when it tries to match root->query_pathkeys. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] PoC: full merge join on comparison clause

-- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/executor/nodeMergejoin.c b/src/backend/executor/nodeMergejoin.c index f50205ec8a..861327b928 100644 --- a/src/backend/executor/nodeMergejoin.c +++ b/src/backend/executor

ERROR: left and right pathkeys do not match in mergejoin

to fix this, so any help is welcome. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Rangejoin rebased

on was added in commit 834ddc62, see right_merge_direction(). Sadly, I have no idea how to solve this. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

hat the lock doesn't have to be acquired inside this function, it can be done by the caller. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] Proposal for CSN based snapshots

I did some work in this direction, namely, made SLRUs use a dynahash table instead of linear search for page->buffer lookups. This is included in the v8 I posted earlier, but it should probably be done as a separate patch. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: [HACKERS] PoC: full merge join on comparison clause

Here is the patch rebased to a852cfe9. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company diff --git a/src/backend/executor/nodeMergejoin.c b/src/backend/executor/nodeMergejoin.c index ef9e1ee471..c842ed2968 100644 --- a/src/backend/executor