Re: BRIN range operator class

From: Emre Hasegeli <emre(at)hasegeli(dot)com>
To: Andreas Karlsson <andreas(at)proxel(dot)se>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, Emanuel Calvo <3manuek(at)esdebian(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: Re: BRIN range operator class
Date: 2015-04-06 19:36:33
Message-ID: CAE2gYzwzdxNSgZBR=qnpeM4jivzB9UR9iOmWKdSY92HrSgS8-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Yeah, there is still a test which fails in opr_sanity.

I attached an additional patch to remove extra pg_amproc entries from
minmax operator classes. It fixes the test as a side effect.

>> Yes but they were also required by this patch. This version adds more
>> functions and operators. I can split them appropriately after your
>> review.
>
>
> Ok, sounds fine to me.

It is now split.

> = New comments
>
> - Searching for the empty range is slow since the empty range matches all
> brin ranges.
>
> EXPLAIN ANALYZE SELECT * FROM foo WHERE r = '[1,1)';
> QUERY PLAN
> -----------------------------------------------------------------------------------------------------------------------
> Bitmap Heap Scan on foo (cost=12.01..16.02 rows=1 width=14) (actual
> time=47.603..47.605 rows=1 loops=1)
> Recheck Cond: (r = 'empty'::int4range)
> Rows Removed by Index Recheck: 200000
> Heap Blocks: lossy=1082
> -> Bitmap Index Scan on foo_r_idx (cost=0.00..12.01 rows=1 width=0)
> (actual time=0.169..0.169 rows=11000 loops=1)
> Index Cond: (r = 'empty'::int4range)
> Planning time: 0.062 ms
> Execution time: 47.647 ms
> (8 rows)

There is not much we can do about it. It looks like the problem in
here is the selectivity estimation.

> - Found a typo in the docs: "withing the range"

Fixed.

> - Why have you removed the USE_ASSERT_CHECKING code from brin.c?

Because it doesn't work with the new operator class. We don't set the
union field when there are elements that are not mergeable.

> - Remove redundant "or not" from "/* includes empty element or not */".

Fixed.

> - Minor grammar gripe: Change "Check that" to "Check if" in the comments in
> brin_inclusion_add_value().

Fixed.

> - Wont the code incorrectly return false if the first added element to an
> index page is empty?

No, column->bv_values[2] is set to true for the first empty element.

> - Would it be worth optimizing the code by checking for empty ranges after
> checking for overlap in brin_inclusion_add_value()? I would imagine that
> empty ranges are rare in most use cases.

I changed it for all empty range checks.

> - Typo in comment: "If the it" -> "If it"
>
> - Typo in comment: "Note that this strategies" -> "Note that these
> strategies"
>
> - Typo in comment: "inequality strategies does not" -> "inequality
> strategies do not"
>
> - Typo in comment: "geometric types which uses" -> "geometric types which
> use"

All of them are fixed.

> - I get 'ERROR: missing strategy 7 for attribute 1 of index "bar_i_idx"'
> when running the query below. Why does this not fail in the test suite? The
> overlap operator works just fine. If I read your code correctly other
> strategies are also missing.
>
> SELECT * FROM bar WHERE i = '::1';

I fixed it on the new version. Tests wasn't failing because they were
using minimal operator class for quality.

> - I do not think this comment is true "Used to determine the addresses have
> a common union or not". It actually checks if we can create range which
> contains both ranges.

Changed as you suggested.

> - Compact random spaces in "select numrange(1.0, 2.0) + numrange(2.5, 3.0); -- should fail"

There was a tab in there. Now it is replaced with a space.

Attachment Content-Type Size
brin-inclusion-v05-box-vs-point-operators.patch application/octet-stream 19.4 KB
brin-inclusion-v05-fix-brin-deform-tuple.patch application/octet-stream 2.3 KB
brin-inclusion-v05-inclusion-opclasses.patch application/octet-stream 76.1 KB
brin-inclusion-v05-remove-assert-checking.patch application/octet-stream 4.2 KB
brin-inclusion-v05-remove-minmax-amprocs.patch application/octet-stream 34.0 KB
brin-inclusion-v05-sql-level-support-functions.patch application/octet-stream 37.6 KB
brin-inclusion-v05-strategy-numbers.patch application/octet-stream 4.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-04-06 20:19:56 Re: Freeze avoidance of very large table.
Previous Message Tom Lane 2015-04-06 18:52:18 Re: BUG #12989: pg_size_pretty with negative values