On Fri, Jul 19, 2019 at 02:37:19PM -0400, Tom Lane wrote:
Tomas Vondra writes:
[ mcv fixes ]
These patches look OK to me.
OK, thanks. Pushed.
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Tomas Vondra writes:
> [ mcv fixes ]
These patches look OK to me.
regards, tom lane
On Thu, Jul 18, 2019 at 11:16:08AM -0400, Tom Lane wrote:
Tomas Vondra writes:
I've pushed the fixes listed in the previous message, with the exception
of the collation part, because I had some doubts about that.
Sorry for being slow on this.
Now, for the collation part - after some more th
Tomas Vondra writes:
> I've pushed the fixes listed in the previous message, with the exception
> of the collation part, because I had some doubts about that.
Sorry for being slow on this.
> Now, for the collation part - after some more thought and looking at code
> I think the fix I shared befo
Hi,
I've pushed the fixes listed in the previous message, with the exception
of the collation part, because I had some doubts about that.
1) handling of NULL values in Cons / MCV items
The handling of NULL elements was actually a bit more broken, because it
also was not quite correct for NULL v
OK, attached is a sequence of WIP fixes for the issues discussed here.
1) using column-specific collations (instead of type/default ones)
The collations patch is pretty simple, but I'm not sure it actually does
the right thing, particularly during estimation where it uses collation
from the Var
On Sat, Jul 13, 2019 at 11:39:55AM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Thu, Jul 11, 2019 at 05:08:22PM +0200, Tomas Vondra wrote:
On Wed, Jul 10, 2019 at 06:48:16PM -0400, Tom Lane wrote:
The right way to determine operator semantics is to look to see
whether they are in a btree op
Tomas Vondra writes:
> On Thu, Jul 11, 2019 at 05:08:22PM +0200, Tomas Vondra wrote:
>> On Wed, Jul 10, 2019 at 06:48:16PM -0400, Tom Lane wrote:
>>> The right way to determine operator semantics is to look to see
>>> whether they are in a btree opclass. That's what the rest of the
>>> planner do
On Thu, Jul 11, 2019 at 05:08:22PM +0200, Tomas Vondra wrote:
On Wed, Jul 10, 2019 at 06:48:16PM -0400, Tom Lane wrote:
Oh ... while we're piling on here, it just sunk into me that
mcv_get_match_bitmap is deciding what the semantics of an operator
are by seeing what it's using for a selectivity
On Wed, Jul 10, 2019 at 06:48:16PM -0400, Tom Lane wrote:
Oh ... while we're piling on here, it just sunk into me that
mcv_get_match_bitmap is deciding what the semantics of an operator
are by seeing what it's using for a selectivity estimator.
That is just absolutely, completely wrong. For star
On Thu, Jul 11, 2019 at 09:55:01AM +0900, Michael Paquier wrote:
On Wed, Jul 10, 2019 at 11:26:09PM +0200, Tomas Vondra wrote:
Yeah, that's a bug. Will fix (not sure how yet).
Please note that I have added an open item for it.
Thanks.
--
Tomas Vondra http://www.2ndQuadrant.
On Wed, Jul 10, 2019 at 11:26:09PM +0200, Tomas Vondra wrote:
> Yeah, that's a bug. Will fix (not sure how yet).
Please note that I have added an open item for it.
--
Michael
signature.asc
Description: PGP signature
Oh ... while we're piling on here, it just sunk into me that
mcv_get_match_bitmap is deciding what the semantics of an operator
are by seeing what it's using for a selectivity estimator.
That is just absolutely, completely wrong. For starters, it
means that the whole mechanism fails for any operat
On Wed, Jul 10, 2019 at 05:45:24PM -0400, Tom Lane wrote:
Tomas Vondra writes:
Yeah, that's a bug. Will fix (not sure how yet).
You could do worse than replace this:
ok = (NumRelids(clause) == 1) &&
(is_pseudo_constant_clause(lsecond(expr->args)) ||
(varonleft =
Tomas Vondra writes:
> Yeah, that's a bug. Will fix (not sure how yet).
You could do worse than replace this:
ok = (NumRelids(clause) == 1) &&
(is_pseudo_constant_clause(lsecond(expr->args)) ||
(varonleft = false,
is_pseudo_constant_clause(linitial(
Tomas Vondra writes:
> BTW which other thread? I don't see any other threads mentioning this
> function.
https://www.postgresql.org/message-id/flat/CA%2Bu7OA65%2BjEFb_TyV5g%2BKq%2BonyJ2skMOPzgTgFH%2BqgLwszRqvw%40mail.gmail.com
regards, tom lane
On Wed, Jul 10, 2019 at 04:57:54PM -0400, Tom Lane wrote:
Andreas Seltenreich writes:
running sqlsmith on the regression database of REL_12_STABLE at
ff597b656f yielded a crash in mcv_get_match_bitmap. I can reproduce it
with the following query on the regression database:
select filler1 f
Andreas Seltenreich writes:
> running sqlsmith on the regression database of REL_12_STABLE at
> ff597b656f yielded a crash in mcv_get_match_bitmap. I can reproduce it
> with the following query on the regression database:
> select filler1 from mcv_lists where a is not null and (select 42) <=
Hi,
running sqlsmith on the regression database of REL_12_STABLE at
ff597b656f yielded a crash in mcv_get_match_bitmap. I can reproduce it
with the following query on the regression database:
select filler1 from mcv_lists where a is not null and (select 42) <= c;
Backtrace below.
regards,
19 matches
Mail list logo
