Attached patches add SP-GiST support to the inet datatypes. The operator
class comes with a small change on the SP-GiST framework to allow fixed
number of child nodes.
The index is like prefix tree except that it doesn't bother to split the
addresses into parts as text is split. It also doesn't
> Emre, I checked original thread and didn't find sample data. Could you
> provide them for testing ?
I found it on the Git history:
https://github.com/job/irrexplorer/blob/9e8b5330d7ef0022abbe1af18291257e044eb24b/data/irrexplorer_dump.sql.gz?raw=true
--
Sent via pgsql-hackers mailing list (p
>> Spgist index tree is much better than gist - 12149 pages vs 1334760 !
I assume this is the reason why it is bigger. IP addresses are very
well suited to SP-GiST. They naturally do not overlap.
> I also noticed, that spgist is much faster than gist for other inet
> operators. I'd like to see
>> In create_opclass.sgml, not only do we have the list of AMs supporting
>> STORAGE, but there is also a paragraph describing which AMs do what
>> for input datatypes of FUNCTION members (around line 175).
>
> I placed BRIN together with gist/gin/spgist here, namely that the optype
> defaults to t
Here are my first comments. I haven't read the actual index
implementation, yet.
I think traversal value is a useful addition. It is nice that the
implementation for the range types is also changed. My questions
about them are:
Do reconstructedValues is required now? Wouldn't it be cleaner to
Here are my comments about the operator class implementation:
> + *implementation of quad-4d tree over boxes for SP-GiST.
Isn't the whole thing actually 3D?
> + * For example consider the case of intersection.
No need for a new line after this.
> + * A quadrant has bounds, but sp-gist ke
> I guess multicolumn BRIN behaves similarly to B-tree or GiST. But I'm
> no expert, so I need someone knowledgeable to confirm this. If the
> following wording is OK, I will update the patch.
Multicolumn BRIN is like GIN. Every column is indexed separately.
The order of the columns doesn't matte
> + * boxtype_spgist.c
The names on the file header need to be changed, too.
> I'll try to explain with two-dimensional example over points. ASCII-art:
>|
>|
> 1 | 2
>|
> ---+-
>|P
> 3 | 4
>
>>> I'll try to explain with two-dimensional example over points. ASCII-art:
>>
>> Thank you for the explanation. Should we incorporate this with the patch.
>
> added
I have worked on the comments of the patch. It is attached. I hope
it looks more clear than it was before.
>>> + cmp_double(con
> I do not know whether this would be a meaningful improvement for
> common use-cases, though. (It'd help if people were more specific
> about the use-cases they need to work.)
For what its worth, in the company I am working for, InnoGames GmbH,
not being able to alter enums is the number one pai
> I did *not* push the hunk in citext.sgml, since that was alleging support
> that doesn't actually exist in this patch. To make this work for citext,
> we need to add wrapper functions similar to citext's wrappers for
> regexp_matches. And that in turn means a citext extension version bump,
> wh
> Emre, I noticed you modified the commitfest entry
> (https://commitfest.postgresql.org/10/588/) to be for Andrew's
> transactional enum addition patch instead, but didn't change the title.
> I'll revert that as soon as it picks up this latest patch. Do you wish
> to remain a reviewer for this pa
> ... this part of the patch breaks the existing API for SP-GiST opclasses.
> That is a hard sell. It may only matter for one existing opclass in core,
> but unless we have reason to think nobody is using any custom SP-GiST
> opclasses, that is not a pleasant thing to do. How important is it real
> Here is v4, which changes the command from ALTER VALUE to RENAME VALUE,
> for consistency with RENAME ATTRIBUTE.
It looks like we always use "ALTER ... RENAME ... old_name TO
new_name" syntax, so it is better that way. I have noticed that all
the other RENAMEs go through ExecRenameStmt(). We b
> That would require changing it from an AlterEnumStmt to a RenameStmt
> instead. Those look to me like they're for renaming SQL objects,
> i.e. things addressed by identifiers, whereas enum labels are just
> strings. Looking at the implementation of a few of the functions called
> by ExecRenameS
> Aside from the disturbing frequency of 100-to-1 split ratios, it also
> looks like the inclusion of the masklen bit is hardly pulling its weight,
> though that might be a artifact of this data set.
I was expecting this. Including masklen bit to decision was something
we could easily do. It doe
> Got around to looking at this. Attached is a revised version that I think
> is in committable shape. The main non-cosmetic change is that the test
> for "type was created in same transaction as new value" now consists of
> comparing the xmins of the pg_type and pg_enum rows, without consulting
> I started looking at this patch. I'm kind of unhappy with having *both*
> IF EXISTS and IF NOT EXISTS options on the statement, especially since
> the locations of those phrases in the syntax seem to have been chosen
> with a dartboard. This feels way more confusing than it is useful.
> Is ther
> Bottom line here is that I'd rather commit ALTER TYPE RENAME VALUE with
> no EXISTS features and then see it accrete those features together with
> other types of RENAME, when and if there's a will to make that happen.
This sounds like a good conclusion to me.
--
Sent via pgsql-hackers mailin
> Given that you are now familiar with the internals of how enums are
> implemented would it be possible to continue the work and add the "ALTER
> TYPE DROP VALUE " command?
I was thinking to try developing it, but I would be more than happy to
help by testing and reviewing, if someone else would
> Why not just disallow dropping a value that's still in use? That's certainly
> what I would prefer to happen by default...
Of course, we should disallow it. That problem is what to do next.
We cannot just remove the value, because it might still be referenced
from the inner nodes of the indexes
> Emre, are you going to address the above? It would have to be Real
> Soon Now.
Yes, I am working on it. I found more problems, replaced more
algorithms. That took a lot of time. I will post the new version
really soon. I wouldn't feel bad, if you wouldn't have enough time to
review it in th
> I think if we're going to do this it should be separated out as its
> own patch. Also, I think someone should explain what the reasoning
> behind the change is. Do we, for example, foresee that the built-in
> code might be faster or less likely to overflow? Because we're
> clearly taking a ris
> Uh, I thought pg_hypot() was still needed on our oldest supported
> platforms. Or is hypot() already supported there? If not, I suppose we
> can keep the HYPOT() macro, and have it use hypot() on platforms that
> have it and pg_hypot elsewhere? That particular fraction of 0001 seemed
> a bit d
> Now, it's also not clear that anything in PG really cares. But if we
> do care, I think we should keep pg_hypot() ... and maybe clarify the
> comment a bit more.
I am not sure how useful NaNs are in geometric types context, but we
allow them, so inconsistent hypot() would be a problem. I will
> The patch introduces way to configure FTS based on CASE/WHEN/THEN/ELSE
> construction.
Interesting feature. I needed this flexibility before when I was
implementing text search for a Turkish private listing application.
Aleksandr and Arthur were kind enough to discuss it with me off-list
today.
> I'm mostly happy with mentioned modifications, but I have few questions
> to clarify some points. I will send new patch in week or two.
I am glad you liked it. Though, I think we should get approval from
more senior community members or committers about the syntax, before
we put more effort to
>> This is also effecting lseg ## box operator.
>
> Mmm.. It returns (1.5, 1.5) with the 0004 patch. It is surely a
> point on the second operand but I'm not sure it's right that the
> operator returns a specific point for two parallel segments.
I am changing it to return NULL, when they are paral
> Well, those two results are not contradictory -- notice that you
> switched the order of the values in the comparison. I don't think
> you've really found the explanation yet.
I am sorry I copy-pasted the wrong example:
"select_views" test runs:
> SELECT name, #thepath FROM iexit ORDER BY 1,
Attached patch adds <@, @>, <<@, and @>> operator symbols for inet
datatype to replace <<=, >>=, <<, and >>. <@ and @> symbols are used
for containment for all datatypes except inet, particularly on the
geometric types, arrays; cube, hstore, intaray, ltree extensions.
<@ and @> symbols are standa
> => ALTER TEXT SEARCH CONFIGURATION multi_conf
> ALTER MAPPING FOR asciiword, asciihword, hword_asciipart,
> word, hword, hword_part
> WITH german_ispell (JOIN), english_ispell, simple;
I have something like this in my mind since I dealt with FTS for a
Turkish real estate listing appl
> With such syntax we also don't need the TSL_FILTER flag for lexeme. At
> the current time unaccent extension set this flag to pass a lexeme to
> a next dictionary. This flag is used by the text-search parser. It
> looks like a hard coded solution. User can't change this behaviour.
Exactly.
> Ma
The BRIN Bitmap Index Scan has the same problem. I have seen people
confused by this. I think N/A would clearly improve the situation.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
>> Here is a patch to add enum support to btree_gin and btree_gist. I didn't
>> include distance operations, as I didn't think it terribly important, and
>> there isn't a simple way to compute it sanely and efficiently, so no KNN
>> support.
I don't think we can implement a meaningful distance ope
> Returning to the issue, the following query should give you the
> expected result.
>
> SELECT name, #thepath FROM iexit ORDER BY name COLLATE "C", 2;
Yes, I have worked around it like this. What I couldn't understand is
how my patch can cause this regression. How is it passes on master
withou
> - I am not convinced that your changes to the descriptions of the operators
> necessarily make things clearer. For example "is contained by and smaller
> network (subnet)" only mentions subnets and not IP-addresses.
I was trying to avoid confusion. <@ is the "contained by" operator
which is als
> The reason for that is that you forgot to edit an alternative
> exptect file, which matches for en_US locale.
Now I understand. Thank you for the explanation.
> But the test doesn't for collation and the only difference
> between the alternative expect files comes from the difference of
> coll
> We can remove the fuzz factor altogether but I think we also
> should provide a means usable to do similar things. At least "is
> a point on a line" might be useless for most cases without any
> fuzzing feature. (Nevertheless, it is a problem only when it is
> being used to do that:) If we don't
> What way to deal with it is in your mind? The problem hides
> behind operators. To fix it a user should rewrite a expression
> using more primitive operators. For example, (line_a # point_a)
> should be rewritten as ((point_a <-> lineseg_a) < EPSILON), or in
> more primitive way. I regared this t
> The new names might be better if we were starting in a green field,
> but in themselves they are not any more mnemonic than what we had, and
> what we had has been there for a lot of years. Also, if we accept both
> old names and new (which it seems like we'd have to), that creates new
> opportu
> To keep such kind of integrity, we should deeply consider about
> errors.
My point is that I don't think we can keep integrity together with the
fuzzy behaviour, or at least I don't have the skills to do that. I
can just leave the more complicated operators like "is a
point on a line" as it is,
> The reason this is kind of scary is that it's just blithely assuming
> that the function won't look at the *other* fields of the FmgrInfo.
> If it did, it would likely get very confused, since those fields
> would be describing the GIN support function, not the function we're
> calling.
I am sor
> Will Emre be around to make the required changes to the patch? I see
> it's been a while since it was originally posted.
I am around. I can post an update in a few days. Thank you for
picking this up.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
> I don't know if this is the only problem
> I'll be in this general area today, so will mention if I stumble over
> anything that looks broken.
I was testing the same patch with a large dataset and got a different segfault:
> hasegeli=# explain select * from only mp_notification_20170225 where
> This can crash at line:414, if either tuple is invalid memory(but I
> think it's not because we have already accessed this memory in above
> if check) or dtup is invalid (this is also not possible because
> brin_new_memtuple has already accessed this).
I was testing with the brin correlation pat
> With my test case, I could not crash even with this patch applied.
> Can you provide your test case?
Yes:
> hasegeli=# create table r2 as select (random() * 3)::int as i from
> generate_series(1, 100);
> SELECT 100
> hasegeli=# create index on r2 using brin (i);
> CREATE INDEX
> hasege
> Please verify the fix.
The same test with both of the patches applied still crashes for me.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Are you getting the crash with the same test case?
Yes. Here is the new backtrace:
> * thread #1: tid = 0x51828fd, 0x000100caf314
> postgres`tbm_prepare_shared_iterate [inlined] pg_atomic_write_u32_impl(val=0)
> at generic.h:57, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_A
> Hopefully, this time I got it correct. Since I am unable to reproduce
> the issue so I will again need your help in verifying the fix.
It is not crashing with the new patch. Thank you.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
> 1.
>
> + Assert(nnumbers == 1);
>
> I think its a bad idea to Assert() this. The stat tuple can come from
> a plugin which could do anything. Seems like if we need to be certain
> of that then it should be an elog(ERROR), maybe mention that we
> expected a 1 element array, but got elements.
But
I wanted to check the patch last time and found a bug effecting
MVC vs MVC part of the join selectivity. Fixed version attached.
Emre Hasegeli :
> Comparing the lists with each other slows down the function when
> statistics set to higher values. To avoid this problem I only use
> log(
Joshua Yanovski :
> Proof of concept initial patch for enabling index only scans for
> partial indices even when an attribute is not in the target list, as
> long as it is only used in restriction clauses that can be proved by
> the index predicate. This also works for index quals, though they
> s
Thank you for looking at it.
> In inet_his_inclusion_selec function,
> When the constant matches only the right side of the bucket, and if it’s a
> last bucket then it's never considered as partial match candidate.
> In my opinion, if it's not a last bucket then for next bucket it will become
>
> I have one last comment, after clarifying this I can move it to "ready for
> committer".
> 1. In networkjoinsel, For avoiding the case of huge statistics, only some of
> the values from mcv and histograms are used (calculated using SQRT).
> -- But in my opinion, if histograms and mcv both are e
The first two shapes on src/test/regress/sql/polygon.sql do not make
sense to me. They look more like polygons with some more tabs,
but still did not match the coordinates. I changed them to make
consistent with the shapes. I believe this was the intention of
the original author. Patch attached
> That seems like a nonstarter :-(. Index-only scans don't have a license
> to return approximations. If we drop the behavior for circles, how much
> functionality do we have left?
It should work with exact operator classes, box_ops, point_ops,
range_ops, inet_ops.
--
Sent via pgsql-hackers m
> Well, I think the number of tabs that makes them look best depends on
> your tab-stop setting. At present, I find that with 8-space tabs
> things seem to line up pretty well, whereas with your patch, 4-space
> tabs line up well. Either way, I have no idea what the picture is
> supposed to mean,
> > 1. This patch introduces a new "polygon <-> point" operator. That seems
> > useful on its own, with or without this patch.
>
> Yeah, but exact-knn cant come with no one implementation. But it would
> better come in a separate patch.
I tried to split them. Separated patches are attached. I c
> Not sure what you mean here. I'm not speaking of the brin index am, I
> mean the get_index_stats_hook call which you've added.
I see. Actually this part was from Alvaro. I haven't noticed the
get_index_stats_hook call before, but it is still the same coding as
btcostestimate(). btcostestimate
> If we want to have a variable which stores the number of ranges, then
> I think numRanges is better than numBlocks. I can't imagine many
> people would disagree there.
I renamed it with other two.
> At the very least please write a comment to explain this in the code.
> Right now it looks broke
- cond := format('%I %s %L', r.colname, r.oper, r.value);
+ cond := format('%s %s %L', r.colname, r.oper, r.value);
Why did you change this? It seems unrelated.
Must be a mistake.
+ indexRel = index_open(index->indexoid, AccessShareLock);
+ pagesPerRange = Min(BrinGetPagesPerRange(indexRel), ba
> Interested to hear comments on this.
I don't have chance to test it right now, but I am sure it would be an
improvement over what we have right now. There is no single correct
equation with so many unknowns we have.
> *indexTotalCost += (numTuples * *indexSelectivity) *
(cpu_index_tuple_cos
> Good point. That's wrong, but I'm confused at why you kept the:
>
> + *indexTotalCost += selec * numTuples * cpu_index_tuple_cost;
>
> at all if that's the case. All the BRIN scan is going to do is build a
> bitmap of the matching ranges found.
My mind was not clear when I was working on it a ye
> Hello, sorry to late for the party, but may I comment on this?
Thank you for picking this up again.
> The first patch reconstructs the operators in layers. These
> functions are called very frequently when used. Some function are
> already inlined in float.h but some static functions in float.h
> Does this need fixing, and if so how?
My improve geometric types patch [1] fixes this issue, by cosidering
NaNs larger than any non-NAN same as the float types. There are many
issues with the geometric types similar to this. Let's combine our
efforts to put them into a shape.
[1]
https://www
> The patch replace pg_hypot with hypot in libc. The man page says
> as follows.
>
> man 3 hypot
>> If the result overflows, a range error occurs, and the functions return
>> HUGE_VAL, HUGE_VALF, or HUGE_VALL, respectively.
> ..
>>ERRORS
>> See math_error(7) for information on how
>> to handle DROP dependency behaviors properly. (On reflection, maybe
>> better if it's "bernoulli(internal) returns tablesample_handler",
>> so as to guarantee that such a function doesn't create a conflict with
>> any user-defined function of the same name.)
>
> The probability of conflict seem
> Emre Hasegeli told me on IM he's going to submit a patch to add
> something similar for the inclusion opclass framework.
It is attached. Thank you for pushing forward to improve the documentation.
0001-Improve-BRIN-documentation-for-Inclusion-opclass.patch
Description: Binary dat
2014/1/9 Oskari Saarenmaa :
> The only useful feature of the uuid-ossp module in my opinion is the
> uuid_generate_v4 function and as uuid-ossp is more or less abandonware
> people have had trouble building and installing it. This patch implements
> an alternative uuid v4 generation function in pg
2014-01-19 Andreas Karlsson :
> Hi,
>
> I will review your two patches (gist support + selectivity). This is part 1
> of my review. I will look more into the actual GiST implementation in a
> couple of days, but thought I could provide you with my initial input right
> away.
Thank you for looking
2014-01-19 12:10, Emre Hasegeli :
> 2014-01-19 Andreas Karlsson :
>
>> I am a bit suspicious about your memcmp based optimization in bitncommon,
>> but it could be good. Have you benchmarked it compared to doing the same
>> thing with a loop?
>
> I did, when I wa
Hi,
This is my review about 3th version of the patch. It is an useful
improvement in my opinion. It worked well on my environment.
2013-12-11 17:43:06, Sergey Muraviov :
> It works in expanded mode when either format option is set to wrapped
> (\pset format wrapped), or we have no pager, or pager
2014-02-16 18:37, Sergey Muraviov :
> New code doesn't work with empty strings but I've done minor optimization
> for this case.
It seems better now. I added some new lines and spaces, removed unnecessary
parentheses and marked it as "Ready for Committer".
fix_psql_print_aligned_vertical_v5.pat
2014-02-17 22:16, Tom Lane :
> More generally, it doesn't look to me like these upgrade scripts are
> complete; shouldn't they be creating some new objects, not just replacing
> old ones?
The actual patches are on the previous mail [1]. I was just trying
to solve the problem that btree_gist canno
2014-02-19 16:52, Tom Lane :
> Not at all, AFAICS. If it were okay to decide that some formerly-default
> opclass is no longer default, then having such a command would be better
> than manually manipulating pg_opclass.opcdefault --- but extension upgrade
> scripts could certainly do the latter if
2014-02-20 01:37, Tom Lane :
> Perhaps it would be acceptable to drop the btree_gist implementation
> and teach pg_upgrade to refuse to upgrade if the old database contains
> any such indexes. I'm not sure that solves the problem, though, because
> I think pg_upgrade will still fail if the opclas
2014-02-24 02:44, Andreas Karlsson :
> Note: The patches do not apply anymore due to changes to
> src/backend/utils/adt/Makefile.
I will fix it on the next version.
> I see, thanks for the explanation. But I am still not very fond of how that
> code is written since I find it hard to verify the
2014-02-24 17:55, Bruce Momjian :
> pg_upgrade has _never_ modified the old cluster, and I am hesitant to do
> that now. Can we make the changes in the new cluster, or in pg_dump
> when in binary upgrade mode?
It can be possible to update the new operator class in the new cluster
as not default,
2014-02-27 18:15, Florian Pflug :
>> It can be possible to update the new operator class in the new cluster
>> as not default, before restore. After the restore, pg_upgrade can upgrade
>> the btree_gist extension and reset the operator class as the default.
>> pg_upgrade suggests to re-initdb the n
2014-02-28 17:30, Florian Pflug :
> Hm, what if we put the new opclass into an extension of its own, say
> inet_gist,
> instead of into core?
It will work but I do not think it is better than adding it in core as
not default.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
> This was already fixed for GiST.
> See following discussion
> http://www.postgresql.org/message-id/capphfdvgticgniaj88vchzhboxjobuhjlm6c09q_op_u9eo...@mail.gmail.com
> and commit
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3c29b196b0ce46662cb9bb7a1f91079fbacbcabb
> "Consis
>> Pls. don't misunderstand my questions: They are directed to get an
>> even more useful spatial data handling of PostgreSQL. I'm working with
>> PostGIS since years and are interested in any work regarding spatial
>> types...
>>
>> Can anyone report use cases or applications of these built-in geo
> Currently PostgreSQL only has trigonometric functions that work in
> radians. I think it would be quite useful to have an equivalent set of
> functions that worked in degrees. In other environments these are
> commonly spelled sind(), cosd(), etc.
I would prefer gradian over degree.
--
Sent v
Thank you for working on this.
I tried the patch with a Turkish dictionary [1] I could find on the
Internet. It worked for some words, but not others:
> hasegeli=# create text search dictionary hunspell_tr (template = ispell,
> dictfile = tr, afffile = tr);
> CREATE TEXT SEARCH DICTIONARY
>
> h
> Judging from a quick look, I think patches 1 and 5 can be committed
> quickly; they imply no changes to other parts of BRIN. (Not sure why 1
> and 5 are separate. Any reason for this?) Also patch 2.
Not much reason except that 1 includes only functions, but 5 includes operators.
> Patch 4 lo
> Indeed, I have done some testing of the patch but more people testing would
> be nice.
The inclusion opclass should work for other data types as long
required operators and SQL level support functions are supplied.
Maybe it would work for PostGIS, too.
--
Sent via pgsql-hackers mailing list (
> Nice, I think it is ready now other than the issues Alvaro raised in his
> review[1]. Have you given those any thought?
I already replied his email [1]. Which issues do you mean?
[1]
http://www.postgresql.org/message-id/CAE2gYzxQ-Gk3q3jYWT=1enlebsgcgu28+1axml4omcwjbkp...@mail.gmail.com
--
> Can you please explain what is the purpose of patch 07? I'm not sure I
> understand; are we trying to avoid having to add pg_amproc entries for
> these operators and instead piggy-back on btree opclass definitions?
> Not too much in love with that idea; I see that there is less tedium in
> that
>> Looking at patch 04, it seems to me that it would be better to have
>> the OpcInfo struct carry the typecache struct rather than the type OID,
>> so that we can avoid repeated typecache lookups in brin_deform_tuple;
>
> Here's the patch.
Looks better to me. I will incorporate with this patch.
> I pushed patches 04 and 07, as well as adopting some of the changes to
> the regression test in 06. I'm afraid I caused a bit of merge pain for
> you -- sorry about that.
No problem. I rebased the remaining ones.
brin-inclusion-v09-02-strategy-numbers.patch
Description: Binary data
brin-in
> I agree with you that we can support other join type and anti join later,
> If others don’t have any objection in doing other parts later I will mark as
> "Ready For Committer".
I updated the patch to cover semi and anti joins with eqjoinsel_semi().
I think it is better than returning a constan
> * Isn't "X >> Y" equivalent to "network_scan_first(X) < Y AND
> network_scan_last(X) > Y"? Or at least close enough for selectivity
> estimation purposes? Pardon my ignorance - I'm not too familiar with the
> inet datatype - but how about just calling scalarineqsel for both bounds?
Actually,
> Heikki Linnakangas writes:
> > * inet_mcv_join_selec() is O(n^2) where n is the number of entries in
> > the MCV lists. With the max statistics target of 1, a worst case
> > query on my laptop took about 15 seconds to plan. Maybe that's
> > acceptable, but you went through some trouble to
> What you did there is utterly unacceptable from a modularity standpoint;
> and considering that the values will be nowhere near right, the argument
> that "it's better than returning a constant" seems pretty weak. I think
> you should just take that out again.
I will try to come up with a bette
> > > I updated the patch to cover semi and anti joins with eqjoinsel_semi().
> > > I think it is better than returning a constant.
> >
> > What you did there is utterly unacceptable from a modularity standpoint;
> > and considering that the values will be nowhere near right, the argument
> > that
I added the point to polygon distance operator patch to the open
CommitFest as ready for committer and added myself as reviewer to
both of the patches.
> I think that for most use cases just some operators require further sorting
> and some of them not. But it could appear one day that some index
> No. And we don't know how to change the default opclass without
> breaking things, either. See previous discussions about how we
> might fix the totally-broken default gist opclass that btree_gist
> creates for the inet type [1]. The motivation for getting rid of that
> is *way* stronger than
> > Changing the default opclasses should work if we make
> > pg_dump --binary-upgrade dump the default opclasses with indexes
> > and exclusion constraints. I think it makes sense to do so in
> > --binary-upgrade mode. I can try to come with a patch for this.
>
> Can you explain it a bit more d
> > While looking it at I found a bug. It returns the second column
> > in wrong order when both of the distance functions return recheck = true.
> > Test script attached to run on the regression database. I tried to
> > fix but could not. searchTreeItemDistanceRecheck function is not
> > very e
> I managed to break it again by ordering rows only by the second column
> of the index. Test script attached.
I was confused. It is undefined behavior. Sorry for the noise.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
1 - 100 of 141 matches
Mail list logo
