Re: Quadratic planning time for ordered paths over partitioned tables

On Fri, Jan 24, 2025 at 2:37 PM Alvaro Herrera wrote: > I ran Kuzmenkov's test case with Watari-san's patch. Planning time goes > from 2700ms to 600ms or so. Thank you, good to know that it helps this case as well.

Re: Quadratic planning time for ordered paths over partitioned tables

On Wed, Jan 22, 2025 at 6:15 PM Tom Lane wrote: > Really I'd think the right place to be fixing this is at a higher > level. Where are the repetitive find_ec_member_matching_expr calls > coming from? I'm not aware of the repeated calls for the same child, and I mostly see it called once for ever

Re: Quadratic planning time for ordered paths over partitioned tables

On Wed, Jan 22, 2025 at 5:36 PM Alvaro Herrera wrote: > I think this is closely related to the work Yuya Watari has been doing > at > https://postgr.es/m/caj2pmkzzhrhgq5uv0y+stkqx7xvgzenmhl98ubkm-oarvk9...@mail.gmail.com > Perhaps you could contribute by reviewing that patch series. Yeah, I'm ref

Quadratic planning time for ordered paths over partitioned tables

www.postgresql.org/message-id/flat/CAJ2pMkZNCgoUKSE%2B_5LthD%2BKbXKvq6h2hQN8Esxpxd%2Bcxmgomg%40mail.gmail.com --- Alexander Kuzmenkov Timescale From 4bc0c6d0ef14006b2dea8db871ba0e4a247bec71 Mon Sep 17 00:00:00 2001 From: Alexander Kuzmenkov <36882414+ak...@users.noreply.github.com> Date

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 libra

Correct SQLSTATE for ENOMEM in file access

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

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 a/src/ba

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

Incorrect cost for MergeAppend

e the plans I've 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

guess this from the rewritten queries and silently falling back to an inefficient plan for cryptic reasons. -- Alexander Kuzmenkov Timescale

[RFC] ASOF Join

estamp and equi-keys. The nested 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

aforementioned 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/i

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

layer 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

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

s and only have Consts? Or should we have 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

part? I'm sure it has its own 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 +0

Re: Optimze usage of immutable functions as relation

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 Postgr

Re: Removing unneeded self joins

xed this in the new version 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: [PA

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 T

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.postg

Re: Removing unneeded self joins

s, for which the UniqueIndexInfo is not relevant, that's why it was optional 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 versio

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

ent of itself, after all. 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 R

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 Russia

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

new code is covered except for 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 performan

Re: Implement predicate propagation for non-equivalence clauses

mergeclause_eclasses fails at assertion.      */     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

Index Only 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.pos

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

oach. I'll mark 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

checks as a quick fix 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 Prof

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

ications in tracked files git clean -xfd # 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

the scan key 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://w

Re: Index Skip Scan

p scan, we 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

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

se two uses. 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 T

Re: Reopen logfile on SIGHUP

ignal&apropos=0&sektion=0&manpath=Debian+4.0.9&arch=default&format=html -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

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

s 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

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

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

for active 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 J

Re: Removing unneeded self joins

e all 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

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

eclause_list there, because this order is ignored later. select_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.co

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

ng on your 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

27;m fine with being credited as a reviewer. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

Re: Generating partitioning tuple conversion maps faster

   v3 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

Re: Generating partitioning tuple conversion maps faster

it's 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

Re: Generating partitioning tuple conversion maps faster

ide thought, we wouldn't have to go 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/

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

nt to use in this case, or even 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

27;t remove any 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 ad5f5b59265762b3674068ee3656baec3ec66

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

DvJQnN7m2sLH1wLh-_Z2bsw%40mail.gmail.com#camjna7cc4x9yr-vajs-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

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

loss 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 Pos

Re: Reopen logfile on SIGHUP

eSignal 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'

hieve 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

x27;t switched to the new one. With a static 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/

Re: Reopen logfile on SIGHUP

rotate logs properly 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 Po

Re: [HACKERS] [PATCH] Incremental sort

talsort is checked at path level, we don't have to check it again at plan level. 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 -

Re: [HACKERS] [PATCH] Incremental sort

a comment explaining why it can't scan backwards, 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 Com

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 fi

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 Pos

Re: IndexJoin memory problem using spgist and boxes

grind. 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

so 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.

27;m not sure how 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.448

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 pat

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

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

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

r of tuples based 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://www

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

g order of outer 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

ro.ru -- 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/exe

ERROR: left and right pathkeys do not match in mergejoin

ch. I don't know yet how to fix this, so any help is welcome. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company

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

On 29.01.2018 08:40, Ashutosh Bapat wrote: Maybe it's better to separate these two into separate patches so that it's easy to review patches. OK, I'll try doing this. For now, moving the patch entry to the next commitfest. -- Alexander Kuzmenkov Postgres Pro

Re: Rangejoin rebased

ization 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()

. Also, it seems to me that 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

log. 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