Tomas Vondra writes:
> On Thu, Apr 23, 2020 at 03:28:21PM +0800, Richard Guo wrote:
>> A minor comment is that I don't think we need to strip relabel
>> explicitly before calling pull_varnos(), because this function would
>> recurse into T_RelabelType nodes.
> Hmmm, yeah. I think you're right tha
On Thu, Apr 23, 2020 at 03:28:21PM +0800, Richard Guo wrote:
On Thu, Apr 23, 2020 at 6:59 AM Tomas Vondra
wrote:
I've pushed fix with the DEFAULT_NUM_DISTINCT. The input comes from a
set operation (which is where we call generate_append_tlist), so it's
probably fairly unique, so maybe we shoul
On Thu, Apr 23, 2020 at 6:59 AM Tomas Vondra
wrote:
> I've pushed fix with the DEFAULT_NUM_DISTINCT. The input comes from a
> set operation (which is where we call generate_append_tlist), so it's
> probably fairly unique, so maybe we should use input_tuples. But it's
> not guaranteed, so DEFAULT_
On Mon, Apr 20, 2020 at 01:47:29AM +0200, Tomas Vondra wrote:
On Sat, Apr 18, 2020 at 02:23:25PM -0400, James Coleman wrote:
On Thu, Apr 16, 2020 at 9:26 PM Tom Lane wrote:
Tomas Vondra writes:
I think we have essentially three options:
1) assuming there's just a single group
2) assuming ea
On Sat, Apr 18, 2020 at 02:23:25PM -0400, James Coleman wrote:
On Thu, Apr 16, 2020 at 9:26 PM Tom Lane wrote:
Tomas Vondra writes:
> I think we have essentially three options:
> 1) assuming there's just a single group
> 2) assuming each row is a separate group
> 3) something in between
> If
On Thu, Apr 16, 2020 at 9:26 PM Tom Lane wrote:
>
> Tomas Vondra writes:
> > I think we have essentially three options:
> > 1) assuming there's just a single group
> > 2) assuming each row is a separate group
> > 3) something in between
> > If (1) and (2) are worst/best-case scenarios, maybe we s
On Fri, Apr 17, 2020 at 7:13 AM Tomas Vondra
wrote:
> On Thu, Apr 16, 2020 at 08:44:16PM +0200, Tomas Vondra wrote:
> >
> >Yeah, that's not entirely close to me. But maybe it shows us where we to
> >get the unprocessed target list?
> >
>
> I think at the very least this needs to apply the same ch
On Fri, Apr 17, 2020 at 2:44 AM Tomas Vondra
wrote:
> On Thu, Apr 16, 2020 at 12:04:03PM -0400, James Coleman wrote:
> >On Thu, Apr 16, 2020 at 8:22 AM Richard Guo
> wrote:
> >> On Thu, Apr 16, 2020 at 6:35 PM Richard Guo
> wrote:
> >>
> >> Attached is what I'm thinking about this optimization.
Tomas Vondra writes:
> I think we have essentially three options:
> 1) assuming there's just a single group
> 2) assuming each row is a separate group
> 3) something in between
> If (1) and (2) are worst/best-case scenarios, maybe we should pick
> something in between. We have DEFAULT_NUM_DISTINCT
On Thu, Apr 16, 2020 at 8:54 PM Tomas Vondra
wrote:
>
> On Wed, Apr 15, 2020 at 11:26:12AM -0400, James Coleman wrote:
> >On Wed, Apr 15, 2020 at 10:47 AM Tomas Vondra
> > wrote:
> >>
> >> ...
> >>
> >> Yeah. And I'm not even sure having that information would allow good
> >> estimates e.g. for UN
On Wed, Apr 15, 2020 at 11:26:12AM -0400, James Coleman wrote:
On Wed, Apr 15, 2020 at 10:47 AM Tomas Vondra
wrote:
...
Yeah. And I'm not even sure having that information would allow good
estimates e.g. for UNIONs of multiple relations etc.
>> Another option is to use something as simple as
On Thu, Apr 16, 2020 at 08:44:16PM +0200, Tomas Vondra wrote:
On Thu, Apr 16, 2020 at 12:04:03PM -0400, James Coleman wrote:
On Thu, Apr 16, 2020 at 8:22 AM Richard Guo wrote:
On Thu, Apr 16, 2020 at 6:35 PM Richard Guo wrote:
On Wed, Apr 15, 2020 at 10:47 PM Tomas Vondra
wrote:
Wel
On Thu, Apr 16, 2020 at 12:04:03PM -0400, James Coleman wrote:
On Thu, Apr 16, 2020 at 8:22 AM Richard Guo wrote:
On Thu, Apr 16, 2020 at 6:35 PM Richard Guo wrote:
On Wed, Apr 15, 2020 at 10:47 PM Tomas Vondra
wrote:
Well, yeah. The problem is the Unique simply compares the columns
On Thu, Apr 16, 2020 at 8:22 AM Richard Guo wrote:
>
>
> On Thu, Apr 16, 2020 at 6:35 PM Richard Guo wrote:
>>
>>
>> On Wed, Apr 15, 2020 at 10:47 PM Tomas Vondra
>> wrote:
>>>
>>>
>>> Well, yeah. The problem is the Unique simply compares the columns in the
>>> order it sees them, and it does n
On Thu, Apr 16, 2020 at 04:44:10PM +0800, Richard Guo wrote:
On Mon, Apr 13, 2020 at 8:09 AM Tomas Vondra
wrote:
I've been messing with this the whole day, without much progress :-(
I'm 99.% sure it's the same issue described by the quoted comment,
because the plan looks like this:
Ne
On Thu, Apr 16, 2020 at 6:35 PM Richard Guo wrote:
>
> On Wed, Apr 15, 2020 at 10:47 PM Tomas Vondra <
> tomas.von...@2ndquadrant.com> wrote:
>
>>
>> Well, yeah. The problem is the Unique simply compares the columns in the
>> order it sees them, and it does not match the column order desired by
>
On Wed, Apr 15, 2020 at 10:47 PM Tomas Vondra
wrote:
>
> Well, yeah. The problem is the Unique simply compares the columns in the
> order it sees them, and it does not match the column order desired by
> incremental sort. But we don't push down this information at all :-(
>
This is a nice optimi
On Mon, Apr 13, 2020 at 8:09 AM Tomas Vondra
wrote:
>
> I've been messing with this the whole day, without much progress :-(
>
> I'm 99.% sure it's the same issue described by the quoted comment,
> because the plan looks like this:
>
> Nested Loop Left Join
> -> Sample Scan on pg_names
On Wed, Apr 15, 2020 at 10:47 AM Tomas Vondra
wrote:
>
> On Tue, Apr 14, 2020 at 01:16:33PM -0400, James Coleman wrote:
> >On Sun, Apr 12, 2020 at 8:09 PM Tomas Vondra
> > wrote:
> >>
> >> On Sun, Apr 12, 2020 at 12:44:45AM +0200, Tomas Vondra wrote:
> >> >Hi,
> >> >
> >> >I've looked into this a
On Tue, Apr 14, 2020 at 01:16:33PM -0400, James Coleman wrote:
On Sun, Apr 12, 2020 at 8:09 PM Tomas Vondra
wrote:
On Sun, Apr 12, 2020 at 12:44:45AM +0200, Tomas Vondra wrote:
>Hi,
>
>I've looked into this a bit, and at first I thought that maybe the
>issue is in how cost_incremental_sort pic
On Sun, Apr 12, 2020 at 8:09 PM Tomas Vondra
wrote:
>
> On Sun, Apr 12, 2020 at 12:44:45AM +0200, Tomas Vondra wrote:
> >Hi,
> >
> >I've looked into this a bit, and at first I thought that maybe the
> >issue is in how cost_incremental_sort picks the EC members. It simply
> >does this:
> >
> >E
On Mon, Apr 13, 2020 at 02:09:43AM +0200, Tomas Vondra wrote:
> Justin, can you try if this resolves the crashes or if there's something
> else going on?
With your patch, this no longer crashes:
|explain SELECT * FROM information_schema.transforms AS ref_1 RIGHT JOIN
(SELECT 1 FROM pg_catalog.pg_
On Sun, Apr 12, 2020 at 12:44:45AM +0200, Tomas Vondra wrote:
Hi,
I've looked into this a bit, and at first I thought that maybe the
issue is in how cost_incremental_sort picks the EC members. It simply
does this:
EquivalenceMember *member = (EquivalenceMember *)
linitial(key->pk_e
Hi,
I've looked into this a bit, and at first I thought that maybe the issue
is in how cost_incremental_sort picks the EC members. It simply does this:
EquivalenceMember *member = (EquivalenceMember *)
linitial(key->pk_eclass->ec_members);
so I was speculating that maybe there are
Adding -hackers, originally forgotten.
On Sat, Apr 11, 2020 at 10:26:39PM +0200, Tomas Vondra wrote:
> Thanks! I'll investigate.
>
> On Sat, Apr 11, 2020 at 02:19:52PM -0500, Justin Pryzby wrote:
> > frequent crash looks like:
> >
> > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linu
25 matches
Mail list logo
