- if (enable_slope && index->rel->reloptkind == RELOPT_BASEREL)
+ if (enable_slope)
{
...
- if (cpathkey)
- {
- /*
...
Isn't that cpathkey if/else needed in the !enable_slope case?
*PENDING*
I thought I was disabling only a piece of code that was added
on commit 0004.
I will have to go through that part with more time.
On commit 0004 with SET enable_slope = on/off I get
Merge Join
Merge Cond: (t.a = u.a)
-> Index Only Scan using t_a_idx on t
-> Index Only Scan using u_a_idx on u
So even though I don't have a solution I acknowledge that my
assumption was wrong.
I also realized one more timestamp issue: timestamptz -> timestamp /
date is not monotonic at a DST change:
Removed prosupport for timestamptz <-> timestamp.
> Additionally,
> 0003 lets the planner ignore NULLS FIRST or NULLS LAST in a pathkey
> if the target expression is known to be NOT NULL. This change is is
> independent of SLOPE implementation.
This patch has an issue in the null handling:
CREATE TABLE l (a int); -- one join column can be NULL
CREATE TABLE r (b int NOT NULL); -- other join column NOT NULL
CREATE INDEX ON l (a);
INSERT INTO l VALUES (1), (2), (NULL);
INSERT INTO r VALUES (1), (2);
SELECT l.a FROM l LEFT JOIN r ON l.a = r.b ORDER BY l.a NULLS FIRST
I clearly underestimated this, removed, to try to keep moving
towards committable.
+ <para>
+ <varname>MONOTONICFUNC_INCREASING</varname>: <literal>x1 > x2</literal>
+ implies <literal>f(x1) >= f(x2)</literal>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <varname>MONOTONICFUNC_DECREASING</varname>: <literal>x1 > x2</literal>
+ implies <literal>f(x1) >= f(x2)</literal>
+ </para>
Decreasing should be <= ?
Sorry, that was because the compilation complained about `<` (xml tag opener),
in an attempt to avoid using xml entities to keep the source readable I tried to use
`>`. Now using xml entities `<` and `>`, could use `≥` instead of `>=`
and `≤` instead of `<=`, maybe more stylish, but the `<=` and `>=` is what the
operator look like in postgres query language. Any preference here?
DECREASING and BOTH duplicated, both seem to be mistakes.
Fixed
CREATE TABLE orders?
Fixed
0001 - 0005 for your review. 0006 can wait.
Kind Regards
Alexandre
