Bonjour Vik,
The point of swapping is to a void possibly expensive modulo, but this
should be done on absolute values, otherwise it may not achieve its
purpose as stated by the comment?
Ah, true. How widespread are these architectures that need this special
treatment? Is it really worth
Bonjour Vik,
Here is an updated patch fixing that.
As I said, welcome to arithmetic:-)
Patch v5 applies cleanly.
Doc: I'd consider using an example the result of which is 42 instead of
21, for obvious geek motivations. Possibly gcd(2142, 462) should be ok.
I got it wrong with my
Hello Tom,
Which architecture has single cycle division? I think it's way above
that, based on profiles I've seen. And Agner seems to back me up:
https://www.agner.org/optimize/instruction_tables.pdf
That lists a 32/64 idiv with a latency of ~26/~42-95 cycles, even on a
moder uarch like
On 04/01/2020 09:35, Fabien COELHO wrote:
>>> I'm unsure about gcd(INT_MIN, 0) should error. Possibly 0 would be
>>> nicer?
>>
>>
>> What justification for that do you have?
>
> ISTM that the current implementation has:
>
> \forall int4 n, n \neq MIN_INT4, \gcd(n, 0) = 0 ?
>
> In which case
On Thu, 2 Jan 2020 at 15:13, Tom Lane wrote:
>
> Stephen Frost writes:
> > * Dean Rasheed (dean.a.rash...@gmail.com) wrote:
> >> I'm not objecting to adding it, I'm just curious. In fact, I think
> >> that if we do add this, then we should probably add lcm() at the same
> >> time, since handling
On Sat, 4 Jan 2020 at 09:37, Dean Rasheed wrote:
>
> Well Vik has now provided a numeric implementation and it doesn't
> appear to be too much code.
>
BTW, I did a bit of research into the efficiency of Euclid's
algorithm. It's actually quite interesting:
It turns out that the worst case is
On Mon, Dec 30, 2019 at 3:11 PM Dilip Kumar wrote:
>
> On Thu, Dec 12, 2019 at 9:44 AM Dilip Kumar wrote:
> >
> Yesterday, Tomas has posted the latest version of the patch set which
> contain the fix for schema send part. Meanwhile, I was working on few
> review comments/bugfixes and
On 2020-01-02 14:26, Pavel Stehule wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This patch replaced query
On Tue, 3 Dec 2019 at 11:06, Pengzhou Tang wrote:
>
> Hi Hackers,
>
> I hit an error when updating a view with conditional INSTEAD OF rules, the
> reproduce steps are list below:
>
> CREATE TABLE t1(a int, b int);
> CREATE TABLE t2(a int, b int);
> CREATE VIEW v1 AS SELECT * FROM t1 where b >
Moving to -hackers
I was asking about how to distinguish the index cost component of an indexscan
from the cost of heap.
https://www.postgresql.org/message-id/20200103141427.GK12066%40telsasoft.com
On Fri, Jan 03, 2020 at 09:33:35AM -0500, Jeff Janes wrote:
> > It would help to be able to set
Dean Rasheed writes:
> OTOH, for numeric inputs, this could easily end up needing many
> thousands of divisions and it's not hard to construct inputs that take
> minutes to compute, although this is admittedly with ridiculously
> large inputs (~10^13), and AFAICS, the performance is OK with
>
Dean Rasheed writes:
> That included a change to rewriteTargetListIU() to prevent it from
> adding dummy targetlist entries for unassigned-to attributes for
> auto-updatable views, in case they are no longer simple references to
> the underlying relation. Instead, that is left to
On 04/01/2020 10:34, Fabien COELHO wrote:
> Code comments: gcd(n, 0) = abs(n), not n?
OK, changed.
> Add unlikely() where appropriate.
Any particular place in mind where I didn't already put it?
> I'd deal with int_min and 0 at the beginning and then proceed with
> absoluting the values,
At the top of the thread your co-author argued the beginning of this
work with "findings about the performance of PostgreSQL, MySQL, and
Oracle on various subqueries:"
https://antognini.ch/2017/12/how-well-a-query-optimizer-handles-subqueries/
I launched this test set with your "not_in ..."
Peter Geoghegan writes:
> I've found the actual problem -- it's my ~/.inputrc. Which is read in by
> libreadline at some point (determined this using ltrace).
Ah-hah!
So what we really want here, I guess, is for the test script to suppress
reading of ~/.inputrc, on the same principle that it
Peter Geoghegan writes:
> On Sat, Jan 4, 2020 at 5:57 PM Tom Lane wrote:
>> A quick look at the readline docs suggests that the
>> best way to do that would be to set envar INPUTRC to /dev/null --- could
>> you confirm that that works for you?
> Yes -- "export INPUTRC=/dev/null" also makes it
On Sat, Jan 4, 2020 at 6:17 PM Tom Lane wrote:
> Cool, I'll go commit a fix along those lines. Thanks for tracing
> this down!
Glad to help!
--
Peter Geoghegan
Peter Geoghegan writes:
> On Sat, Jan 4, 2020 at 10:19 AM Tom Lane wrote:
>> Looking closer, I see that your actual output included *both*
>> spaces and escape sequences between the table names, so it
>> needs to be more like the attached.
> This patch makes the tests pass. Thanks!
Ah, good.
On Sat, Jan 4, 2020 at 11:50 AM Tom Lane wrote:
> So we're going to have to make some decisions about what range of
> libedit builds we want to cater for in the tab-completion tests.
> Given that the plan is to considerably increase the coverage of
> those tests, I'm hesitant to promise that
Peter Geoghegan writes:
> With the attached patch against HEAD (which is based on your earlier
> unset-TERM-in-tab-completion-test.patch), I find that the tests fail
> as follows:
Um, well, that's the same behavior you were seeing before.
So the terminfo reinstall didn't really do anything.
I'm
On Sat, Jan 4, 2020 at 5:57 PM Tom Lane wrote:
> So what we really want here, I guess, is for the test script to suppress
> reading of ~/.inputrc, on the same principle that it suppresses reading
> of ~/.psqlrc.
That was what I thought of, too.
> A quick look at the readline docs suggests that
I wrote:
> Peter Geoghegan writes:
>> Once I comment out the following two lines from ~/.inputrc, everything
>> works fine on
>> HEAD + HEAD-unset-TERM-in-tab-completion-test.patch:
>> set colored-completion-prefix on
>> set colored-stats on
> Hm. I wonder how it is that that leads to ignoring
Hello Vik,
Add unlikely() where appropriate.
Any particular place in mind where I didn't already put it?
In GCD implementations, for instance:
if (arg1 == PG_INT32_MIN)
if (arg2 == 0 || arg2 == PG_INT32_MIN)
And possibly a "likely" on the while.
In LCM implementations, for instance:
On Sun, Jan 05, 2020 at 08:54:15AM +0900, Masahiko Sawada wrote:
On Thu, Jan 2, 2020 at 9:09 PM Amit Kapila
wrote:
Hi,
I am starting a new thread for some of the decisions for a parallel
vacuum in the hope to get feedback from more people. There are
mainly two points for which we need some
On Sun, Jan 5, 2020 at 8:30 AM Tom Lane wrote:
>
> Noah Misch writes:
>
> > I generally favor keeping the test, but feel free to decide it's too hard.
>
> I remain dubious that it's worth the trouble, or indeed that the test
> would prove anything of interest.
>
I think we don't have any tests
On Sat, 4 Jan 2020 at 17:55, Vik Fearing wrote:
> On 04/01/2020 10:37, Dean Rasheed wrote:
> >
> > BTW, there is actually no need to restrict the inputs to integral
> > values because GCD is something that has a perfectly natural extension
> > to floating point inputs (see for example [1]).
Hi,
The latest version of this patch (from 2019/09/14) no longer applies,
although maybe it's some issue with patch format (applying it using
patch works fine, git am fails with "Patch format detection failed.").
In any case, this means cputube can't apply/test it.
On Sat, Sep 14, 2019 at
On Sat, Jan 4, 2020 at 3:39 PM Tom Lane wrote:
> Hm, well, HEAD still has the hackery with explicit accounting for
> escape sequences. Could you try it with the patch I showed to unset
> TERM and remove that stuff? (It won't apply exactly to HEAD, but
> the diffs are simple enough, or you could
On 2019-12-02 11:21, Michael Paquier wrote:
On Wed, Nov 27, 2019 at 08:47:06PM +0300, Alexey Kondratov wrote:
Thus, I cannot get your point correctly here. Can you, please,
elaborate a
little bit more your concerns?
The case of REINDEX CONCURRENTLY is pretty simple, because a new
relation
On Sat, Jan 4, 2020 at 10:19 AM Tom Lane wrote:
> Looking closer, I see that your actual output included *both*
> spaces and escape sequences between the table names, so it
> needs to be more like the attached.
This patch makes the tests pass. Thanks!
> So now I'm thinking again that there must
Hi,
This patch was marked as RFC on 2019-03-30, but since then there have
been a couple more issues pointed out in a review by Thomas Munro, and
it went through 2019-09 and 2019-11 without any attention. Is the RFC
status still appropriate?
regards
--
Tomas Vondra
On Sun, Jan 05, 2020 at 01:33:55AM +0100, Tomas Vondra wrote:
> On Wed, Feb 13, 2019 at 11:26:23PM -0800, Noah Misch wrote:
> >a. Fix the rounding in SimpleLruTruncate(). (The patch I posted upthread is
> > wrong; I will correct it in a separate message.)
> >
> >b. Arrange so only one backend
On Sat, 4 Jan 2020 at 17:13, Tom Lane wrote:
>
> Dean Rasheed writes:
> > That included a change to rewriteTargetListIU() to prevent it from
> > adding dummy targetlist entries for unassigned-to attributes for
> > auto-updatable views, in case they are no longer simple references to
> > the
I wrote:
> Meh. I must be too tired to get the regexp syntax right.
Looking closer, I see that your actual output included *both*
spaces and escape sequences between the table names, so it
needs to be more like the attached.
Also, I apparently misread the control sequences. What they
look like
I wrote:
> Seeing that you're also having issues with a stack involving
> libtinfo.so.5, here's my theory: libtinfo version 5 is brain-dead
> about whether it needs to issue cursor repositioning commands, and
> tends to do so even when the cursor is in the right place already.
> Version 6 fixed
On Sun, Jan 5, 2020 at 6:29 AM Tom Lane wrote:
>
> I wrote:
> > Seeing that you're also having issues with a stack involving
> > libtinfo.so.5, here's my theory: libtinfo version 5 is brain-dead
> > about whether it needs to issue cursor repositioning commands, and
> > tends to do so even when
Hi,
This patch is registered in 2020-01, but the last message in the thread
seems to be from 2019/05/23. The patch itself seems to be OK (it applies
fine etc.) What do we need to get it over the line, instead of just
moving it to the next one CF over and over?
regards
--
Tomas Vondra
Tomas Vondra writes:
> On Fri, Jan 03, 2020 at 01:29:23PM +0500, Ibrar Ahmed wrote:
>> I want to be this time. This is my first time doing this.
> It's not clear to me what's the process for picking a CFM when there are
> multiple volunteers.
Up to now we haven't needed a process for that ;-)
Andrew Dunstan writes:
> On Sun, Jan 5, 2020 at 6:29 AM Tom Lane wrote:
>> What has to have broken those machines was the change to explicitly
>> force TERM to "xterm". Now I'm wondering what their prevailing
>> setting was before that. Maybe it was undef, or some absolutely
>> vanilla thing
On Sat, Jan 4, 2020 at 12:56 PM Tom Lane wrote:
> Yeah, there is still something unexplained about that. We've so far
> failed to pin the blame on either readline version or environment
> settings ... but what else could be causing you to get different
> results?
Tom just advised me via private
Peter Geoghegan writes:
> Tom just advised me via private e-mail that my termcap database may be
> the issue here. Looks like he was right. I did a "sudo aptitude
> reinstall ncurses-base", and now the tests pass against HEAD. (I
> probably should have tried to preserve things before going ahead
Noah Misch writes:
> On Sat, Jan 04, 2020 at 06:56:48AM +0530, Amit Kapila wrote:
>> So, where do we go from here? Shall we try to identify why cron is
>> keeping extra FDs or we assume that we can't predict how many
>> pre-opened files there will be?
> The latter. If it helps, you could add a
On Sat, Jan 04, 2020 at 06:19:33PM -0500, Tom Lane wrote:
Tomas Vondra writes:
On Fri, Jan 03, 2020 at 01:29:23PM +0500, Ibrar Ahmed wrote:
I want to be this time. This is my first time doing this.
It's not clear to me what's the process for picking a CFM when there are
multiple
On Sun, Jan 5, 2020 at 12:21 AM Noah Misch wrote:
>
> On Fri, Jan 03, 2020 at 02:20:09PM +0530, Amit Khandekar wrote:
> > On Fri, 3 Jan 2020 at 10:19, Amit Kapila wrote:
> > > On Fri, Jan 3, 2020 at 8:29 AM Amit Kapila
> > > wrote:
> > >> I see one failure in REL_10_STABLE [1] which seems to
On Fri, Jan 03, 2020 at 02:20:09PM +0530, Amit Khandekar wrote:
> On Fri, 3 Jan 2020 at 10:19, Amit Kapila wrote:
> > On Fri, Jan 3, 2020 at 8:29 AM Amit Kapila wrote:
> >> I see one failure in REL_10_STABLE [1] which seems to be due to this
> >> commit:
> >
> > I tried this test on my CentOs
On Fri, Jan 03, 2020 at 01:29:23PM +0500, Ibrar Ahmed wrote:
On Fri, 3 Jan 2020 at 11:51, Michael Paquier wrote:
On Thu, Jan 02, 2020 at 11:34:55PM +0100, Tomas Vondra wrote:
> It's probably time I've done one of these, so if there are no other
> volunteers I'll take care of it this one.
On Sat, Jan 04, 2020 at 10:50:47AM -0600, Justin Pryzby wrote:
> > Doesn't enable_indexscan=off accomplish this already? It is possible but
> > not terribly likely to switch from index to seq, rather than from index to
> > bitmap. (Unless the index scan was being used to obtain an ordered
On 04/01/2020 20:08, Dean Rasheed wrote:
> On Sat, 4 Jan 2020 at 17:55, Vik Fearing wrote:
>> On 04/01/2020 10:37, Dean Rasheed wrote:
>>> BTW, there is actually no need to restrict the inputs to integral
>>> values because GCD is something that has a perfectly natural extension
>>> to floating
Hi,
On Wed, Sep 18, 2019 at 05:29:52PM +0500, Ahsan Hadi wrote:
I don't see much use for this because the documentation says that "server's
execute command cannot be used directly within pl/pgsql function (and it is
not needed). Within pl/pgsql you can execute update/delete commands using
On Wed, Feb 13, 2019 at 11:26:23PM -0800, Noah Misch wrote:
On Sat, Feb 02, 2019 at 03:38:22AM -0500, Noah Misch wrote:
The main consequence is the false alarm.
That conclusion was incorrect. On further study, I was able to reproduce data
loss via either of two weaknesses in the "apparent
On Sat, Jan 04, 2020 at 06:56:48AM +0530, Amit Kapila wrote:
> On Sat, Jan 4, 2020 at 6:19 AM Tom Lane wrote:
> > =?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
> > > I tried starting it from cron and then I got:
> > > max_safe_fds = 981, usable_fds = 1000, already_open = 9
> >
> > Oh! There we
Peter Geoghegan writes:
> FWIW, I find it very surprising that it was possible for the test to
> fail on my workstation/server, without it failing on any buildfarm
> animals.
Yeah, there is still something unexplained about that. We've so far
failed to pin the blame on either readline version
On Sat, Jan 4, 2020 at 12:56 PM Tom Lane wrote:
> Yeah, there is still something unexplained about that. We've so far
> failed to pin the blame on either readline version or environment
> settings ... but what else could be causing you to get different
> results?
Beats me. Could have something
On Thu, Jan 2, 2020 at 9:09 PM Amit Kapila wrote:
>
> Hi,
>
> I am starting a new thread for some of the decisions for a parallel vacuum in
> the hope to get feedback from more people. There are mainly two points for
> which we need some feedback.
>
> 1. Tomas Vondra has pointed out on the
On Sat, Jan 4, 2020 at 4:14 PM Tom Lane wrote:
> Um, well, that's the same behavior you were seeing before.
> So the terminfo reinstall didn't really do anything.
Sigh.
> I'm still curious about which terminfo file your psql actually
> reads if TERM is unset, and whether that file is visibly
>
55 matches
Mail list logo
