>> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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]
> 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
> 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
> 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) *
- 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),
> 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
> 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().
> 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.
> 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
> 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 =
>
> 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
> 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
>
> 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
> 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
> 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
> 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
> As there are a lot of updates I did my best to consolidate some of the
> bullet points and as usual, people are directed to the release notes.
> Please let me know if there are any inaccuracies so I can fix them ASAP.
Just some minor points:
> * Several fixes for PostgreSQL operating in hot
> I think this patch is already in a good shape.
I am sorry for introducing this bug. This fix looks good to me as well.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Got it, but if other people don't agree then this is going nowhere.
Yes. As I wrote, I don't particularly care about functions like "is
point on line". I can prepare a patch to fix as many problems as
possible around those operators by preserving the current epsilon.
I though we were arguing
> Backing up a bit here, have we lost track of the problem that we're
> trying to solve? Tom gave his opinion here:
>
> https://www.postgresql.org/message-id/3895.1464791...@sss.pgh.pa.us
>
> But I don't see that the latest patch I can find does anything to fix
> that.
This is what he wrote:
>
> Even though I'm not sure but I don't see a "natural" (or
> agreeable by many poeple) ordering of geometric types in
> general. Anyway it's quite application (not application program
> but the relationship with the real world) specific.
We can just define it for point as "ORDER BY point.x,
I am responding both of your emails together.
> Perhaps I don't understand it. Many opclass are defined for
> btree. But since (ordinary) btree handles only one-dimentional,
> totally-orderable sets, geometric types even point don't fit
> it. Even if we relaxed it by removing EPSILON,
> - Floating point comparisons for gemetric types
>
> Comparison related to geometric types is performed by FPeq
> macro and similars defined in geo_decls.h. This intends to give
> tolerance to the comparisons.
>
> A
> FPeq: |<=e-|-e=>|(<= means inclusive, e =
> I do not like this bit from the original post:
>
> EH> The patch removes the recently committed SP-GiST index support for the
> EH> existing operator symbols to give move reason to the users to use the
> EH> new symbols.
I reverted this part. The new version of the patch is attached.
> 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
> 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
>
> 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
> 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
> 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
>
> - 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
> 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
>> 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
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
> 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.
>
> => 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
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
> 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,
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> ... 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
> 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
> 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,
>
> It might be more useful after we get the infrastructure that Kevin's been
> working on to allow collecting all the updates into a tuplestore that
> could be passed to a statement-level trigger. Right now I tend to agree
> that there's little point.
Maybe, this can be used to re-implement
> I think that probably the most reasonable answer is to replace all the
> raw "double" comparisons in this code with float8_cmp_internal() or
> something that's the moral equivalent of that. Does anyone want to
> propose something else?
We can probably get away by changing the comparison on the
edback.
From a6f24b34fdb39eaaca1d3819f7f528b1689725a4 Mon Sep 17 00:00:00 2001
From: Emre Hasegeli <e...@hasegeli.com>
Date: Sun, 29 May 2016 18:53:37 +0200
Subject: [PATCH] Add regexp_match()
---
doc/src/sgml/citext.sgml | 5 ++
doc/src/sgml/func.sgml
17 00:00:00 2001
From: Emre Hasegeli <e...@hasegeli.com>
Date: Sun, 29 May 2016 18:53:37 +0200
Subject: [PATCH] Add regexp_match()
---
doc/src/sgml/citext.sgml | 5 ++
doc/src/sgml/func.sgml | 59 +++---
src/backend/catalog/information_sche
> My interpretation of the standard is that FILTER is not allowable for
> a window function, and IGNORE|RESPECT NULLS is not allowable for an
> ordinary aggregate.
Yes, it is clear.
> So if we support IGNORE|RESPECT NULLS for anything other than a window
> function, we have to come up with our
[3] https://www.postgresql.org/message-id/flat/12549.1346111...@sss.pgh.pa.us
[4]
https://www.postgresql.org/message-id/flat/20150512181307.gj2...@alvh.no-ip.org
From aa79e331595860489cdbbdce2d5f35a7d1f33783 Mon Sep 17 00:00:00 2001
From: Emre Hasegeli <e...@hasegeli.com>
Date: Wed, 25 May 2016
I think the variable "magick" should be "magic". Patch attached.
bloom-magick.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Thank you, pushed
Thank you for working on this.
I noticed that have overlooked this:
static RectBox *
-initRectBox()
+initRectBox(void)
{
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
> 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
>>> 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.
>>> +
> + * 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 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
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
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
>> 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
>> 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
> 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
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
> But is it? Is it impossible for the BRIN bitmap index scan to return 0 rows
> (say, if the value being matched is outside the min/max boundary for every
> block range?) Granted, if we document that it always returns 0 and should be
> ignored, then confusing the actual 0 with the 0 as a
> which is much closer to the actual number of rows removed by the index
> recheck + the one left.
Is it better to be closer? We are saying those are the "actual"
values not the estimates. If we cannot provide the actual rows, I
think it is better to provide nothing. Something closer to the
> I don’t see how to solve this problem without changing explain analyze output
> to accommodate for “unknown” value. I don’t think “0” is a non-confusing
> representation of “unknown” for most people, and from the practical
> standpoint, a “best effort” estimate is better than 0 (i.e. I will
> The patch is attached.
Now, it is actually attached.
brin-correlation-v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Somebody wrote to me a few days ago that the BRIN cost estimation is
> rather poor. One immediately obvious issue which I think is easily
> fixed is the correlation estimate, which is currently hardcoded to 1.
>
> Since a BRIN scan always entails a scan of the relation in physical
> order, it's
I was getting segfaults while working on the current master for a while.
This is the shortest way I could found to reproduce the problem:
create or replace function is_distinct_from(anyelement, anyelement)
returns boolean language sql
as 'select $1 is distinct from $2';
create operator !== (
> I checked new snowball site http://snowballstem.org/ and found several new
> stemmers appeared (as external contributions):
>
> Irish and Czech
> Object Pascal codegenerator for Snowball
> Two stemmers for Romanian
> Hungarian
> Turkish
> Armenian
> Basque (Euskera)
> Catalan
>
> Some of them we
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
>
>
> 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
>> 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
> 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
>
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 data
--
Sent
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 seems high with
Emre Hasegeli just pointed out to me that this patch introduced
box_contain_pt() and in doing so used straight C comparison (= etc)
instead of FPlt() and friends. I would think that that's a bug and
needs to be changed -- but certainly not backpatched, because gist
indexes would/might become
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
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.
--
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 the
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
--
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 looks
New version of the patch attached with the optimization to break the
loop before looking at all of the histogram values. I can reduce
join selectivity estimation runtime by reducing the values of the
left hand side or both of the sides, if there is interest.
Even if the above aspects of the
I thought we can do better than minmax for the inet data type,
and ended up with a generalized opclass supporting both inet and range
types. Patch based on minmax-v20 attached. It works well except
a few small problems. I will improve the patch and add into
a commitfest after BRIN
I spent a fair chunk of the weekend hacking on this patch to make
it more understandable and fix up a lot of what seemed to me pretty
clear arithmetic errors in the upper layers of the patch. However,
I couldn't quite convince myself to commit it, because the business
around estimation for
Actually, there's a second large problem with this patch: blindly
iterating through all combinations of MCV and histogram entries makes the
runtime O(N^2) in the statistics target. I made up some test data (by
scanning my mail logs) and observed the following planning times, as
reported by
Once again, many thanks for the review. Here's a new version. I have
added operator classes for int8, text, and actually everything that btree
supports except:
bool
record
oidvector
anyarray
tsvector
tsquery
jsonb
range
since I'm not sure that it
I extracted Emre's diagram adjustments from the patch and applied it,
and no tabs now. Emre, I assume your regression changes did not affect
the diagram contents.
Thank you for looking at it. I wanted to make the tests consistent
with the diagrams. Now they look better but they still don't
1 - 100 of 140 matches
Mail list logo
