Peter Geoghegan writes:
> On Fri, Mar 1, 2019 at 11:56 AM Robert Haas wrote:
>> It would be neat if there were a tool you could run to somehow tell
>> you whether catversion needs to be changed for a given patch.
> That seems infeasible because of stored rules. A lot of things bleed
> into that.
"Li, Zheng" writes:
> Although adding "or var is NULL" to the anti join condition forces the
> planner to choose nested loop anti join, it is always faster compared to the
> original plan.
TBH, I am *really* skeptical of sweeping claims like that. The existing
code will typically produce a has
On Sat, 2 Mar 2019 at 12:13, Tom Lane wrote:
>
> "Li, Zheng" writes:
> > Although adding "or var is NULL" to the anti join condition forces the
> > planner to choose nested loop anti join, it is always faster compared to
> > the original plan.
>
> TBH, I am *really* skeptical of sweeping claims
On 2/28/19 10:13 AM, Christoph Berg wrote:
> Re: Magnus Hagander 2016-04-13
>
>> It's fairly common to see a lot of "Incomplete startup packet" in the
>> logfiles caused by monitoring or healthcheck connections.
> I've also seen it caused by port scanning.
Yes, definitely. Que
On 03/01/19 17:34, Tom Lane wrote:
> but I think it'd be fragile to use. (See the "Type Conversion"
> chapter in the manual for the gory details, and note that domains
> get smashed to their base types mighty readily.)
>
> Using custom operator names would work better/more reliably.
Or a new ba
The current transformation would not add "or s.a is NULL" in the example
provided since it is non-nullable. You will be comparing these two cases in
terms of the transformation:
select count(*) from big b where not exists(select 1 from small s
where s.a = b.a);
Time: 51.416 ms
select count(*) f
Chapman Flack writes:
> On 03/01/19 17:34, Tom Lane wrote:
>> Using custom operator names would work better/more reliably.
> Or a new base type (LIKE float8) rather than a domain?
Yeah, it'd be more work but you would have control over the
coercion rules.
regards, tom la
Andrew Dunstan writes:
> So I propose shortly to commit this patch unconditionally demoting the
> message to DEBUG1.
No patch referenced, but I assume you mean only for the
zero-bytes-received case, right? No objection if so.
regards, tom lane
_bt_lock_branch_parent() is used by VACUUM during page deletion, and
calls _bt_getstackbuf(), which always finishes incomplete page splits
for the parent page that it exclusive locks and returns. ISTM that
this may be problematic, since it contradicts the general rule that
VACUUM isn't supposed to
On Sat, 2 Mar 2019 at 12:39, Li, Zheng wrote:
> However, if s.a is nullable, we would do this transformation:
> select count(*) from big b where not exists(select 1 from small s
> where s.a = b.a or s.a is null);
I understand you're keen to make this work, but you're assuming again
that f
Hello all!
I am Sumukha PK a student of NITK. I am interested in the WAL-G backup tool. I
haven’t been able to catch hold of anyone through the IRC channels so I need
someone to point me to appropriate resources so that I can be introduced to it.
I am proficient in Golang an would be interested
On Fri, Mar 01, 2019 at 05:05:54PM -0500, Joe Conway wrote:
> Seems like it would be better to modify the arguments to
> CloseTransientFile() to include the filename being closed, errorlevel,
> and fail_on_error or something similar. Then all the repeated ereport
> stanzas could be eliminated.
Sur
Peter Geoghegan writes:
> _bt_lock_branch_parent() is used by VACUUM during page deletion, and
> calls _bt_getstackbuf(), which always finishes incomplete page splits
> for the parent page that it exclusive locks and returns. ISTM that
> this may be problematic, since it contradicts the general ru
David Rowley writes:
> I think you're fighting a losing battle here with adding OR quals to
> the join condition.
Yeah --- that has a nontrivial risk of making things significantly worse,
which makes it a hard sell. I think the most reasonable bet here is
simply to not perform the transformation
On Fri, Mar 1, 2019 at 4:41 PM Tom Lane wrote:
> > FWIW, I notice that the logic that appears after the
> > _bt_lock_branch_parent() call to _bt_getstackbuf() anticipates that it
> > must defend against interrupted splits in at least the
> > grandparent-of-leaf page, and maybe even the parent, so
On Fri, Mar 1, 2019 at 5:00 PM Peter Geoghegan wrote:
> I favor keeping the test, but having it throw a
> ERRCODE_INDEX_CORRUPTED error, just like _bt_pagedel() does already. A
> comment could point out that the test is historical/defensive, and
> probably isn't actually necessary. What do you thi
On 3/1/19 6:49 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> So I propose shortly to commit this patch unconditionally demoting the
>> message to DEBUG1.
> No patch referenced, but I assume you mean only for the
> zero-bytes-received case, right? No objection if so.
>
>
Andrew Dunstan writes:
> On 3/1/19 6:49 PM, Tom Lane wrote:
>> No patch referenced, but I assume you mean only for the
>> zero-bytes-received case, right? No objection if so.
> Patch proposed by Christoph Berg is here:
> https://www.postgresql.org/message-id/20190228151336.GB7550%40msg.df7cb.de
Hello David & Surafel,
I think this can be marked as ready for committer now, but I'll defer
to Fabien to see if he's any other comments.
Patch v16 applies and compiles cleanly, local and global "make check"
are ok. Doc build is ok.
I did some manual testing with limit cases which did wor
101 - 119 of 119 matches
Mail list logo