> 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
On Sun, Oct 25, 2015 at 6:16 PM, Emre Hasegeli wrote:
>> 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
On 10/25/2015 10:01 PM, Fabien COELHO wrote:
[...]
So either the information is important and then should be placed in
the docs directly, or it's not and then linking to wikipedia is
pointless because the users are not interested in learning all the
details about each distribution function.
On 17/10/15 04:31, Alvaro Herrera wrote:
> Robert Haas wrote:
>>> The other item on me is the documentation patch by Emre Hasegeli for
>>> usage of the inclusion opclass framework in BRIN. I think it needs some
>>> slight revision by some native English speaker and I'm not completely in
>>> love
2015-10-26 11:12 GMT+09:00 Michael Paquier :
>
>
> On Mon, Oct 26, 2015 at 10:52 AM, Kisung Kim wrote:
>
>> Because of the internal implementation of MVCC in PG
>> the update of a row is actually a insertion of a new version row.
>> So if the size
- Цитат от Kisung Kim (ks...@bitnine.co.kr), на 26.10.2015 в 04:36 -
> However, what I want to know is about the update performance difference
> between PG and Oracle if there any.
> The case I described is for exaggerating the difference between PG and
> Oracle.
>
> I want to explain
On Mon, Oct 26, 2015 at 9:03 AM, Любен Каравелов wrote:
>
>
> - Цитат от Kisung Kim (ks...@bitnine.co.kr), на 26.10.2015 в 04:36
-
>
> > However, what I want to know is about the update performance difference
> > between PG and Oracle if there any.
> > The case I
Dear,
I have a question about update performance of PG.
Because of the internal implementation of MVCC in PG
the update of a row is actually a insertion of a new version row.
So if the size of a row is huge, then it incurs some overhead compare to
in-place update strategy.
Let's assume that a
On 2015/10/23 19:02, Amit Langote wrote:
> On 2015/10/23 18:51, Etsuro Fujita wrote:
>>
>> This is really really nitpicking, but I noticed that there is an implicit
>> rule concerning the message format in ATWrongRelkindError; if more than
>> two objects are present, the message is "\"%s\" is not
> As I stated upthread, PQping("host='0.0.0.0'") is _not portable_. It works on
> GNU/Linux, which I used for that demo. It fails on OpenBSD and Windows.
>
>> I'd be inclined to suggest fixing it like this:
>>
>> /* If postmaster is listening on "*", use localhost
>>
Hi all,
Perhaps some of you guys knew about that, but I just found about this
stuff this morning:
https://boringssl.googlesource.com/boringssl/+/HEAD/PORTING.md
Looking at the porting section many routines have changed compared to
OpenSSL. I can't imagine this fork to become a complete
> On Sat, Jul 25, 2015 at 11:13 PM, Kouhei Kaigai wrote:
> > I'm recently working/investigating on ParallelAppend feature
> > towards the next commit fest. Below is my design proposal.
> >
> > 1. Concept
> > --
> > Its concept is quite simple anybody might consider
On Mon, Oct 26, 2015 at 10:52 AM, Kisung Kim wrote:
> Because of the internal implementation of MVCC in PG
> the update of a row is actually a insertion of a new version row.
> So if the size of a row is huge, then it incurs some overhead compare to
> in-place update
On 19 October 2015 at 21:43, Craig Ringer wrote:
> Hi all
>
> Patch revision 3 attached. It's a one-liner, with just the fix, and an
> explanatory note in the patch header.
I'm bumping this because I think it's important not to miss it for
9.5, so it can't wait for the
Hi,
I've been looking at the checkpoint patches (sorting, flush and FPW
compensation) and realized we got gaussian/exponential distributions in
pgbench which is useful for simulating simple non-uniform workloads.
But I think the current docs is a bit too difficult to understand for
people
On 10/25/2015 08:11 PM, Fabien COELHO wrote:
Hello Tomas,
I've been looking at the checkpoint patches (sorting, flush and FPW
compensation) and realized we got gaussian/exponential distributions
in pgbench which is useful for simulating simple non-uniform workloads.
Indeed.
But I think
[...]
So either the information is important and then should be placed in the
docs directly, or it's not and then linking to wikipedia is pointless
because the users are not interested in learning all the details about
each distribution function.
What is important is that these
On 22 October 2015 at 16:01, Robert Haas wrote:
> If we make Gather projection-capable,
> we can just end up with Gather->PartialSeqScan.
>
Is there a reason not to do projection in the Gather node? I don't see one.
> > That said, I don't understand Tom's comment
On Sun, Oct 25, 2015 at 10:16:41AM +0100, Emre Hasegeli wrote:
> > 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
Hello Tomas,
I've been looking at the checkpoint patches (sorting, flush and FPW
compensation) and realized we got gaussian/exponential distributions in
pgbench which is useful for simulating simple non-uniform workloads.
Indeed.
But I think the current docs is a bit too difficult to
On Sun, Oct 25, 2015 at 11:59 AM, Simon Riggs wrote:
> On 22 October 2015 at 16:01, Robert Haas wrote:
>> If we make Gather projection-capable,
>> we can just end up with Gather->PartialSeqScan.
>
> Is there a reason not to do projection in the
On 10/22/15 6:39 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
That would be the minimal-impact version, yes. But I suspect if we went
through the trouble to do that, it would be just as easy to attempt the
freeze regardless of what scan_all is set to.
You mean if !scan_all we conditional-get
22 matches
Mail list logo