On Thu, Feb 2, 2017 at 4:57 PM, Rafia Sabih
wrote:
> On Thu, Feb 2, 2017 at 1:19 AM, Thomas Munro
> wrote:
>> On Thu, Feb 2, 2017 at 3:34 AM, Rafia Sabih
>> wrote:
>>> [ regressions ]
>>
>> Thanks Rafia.
Hi hackers,
I wonder why SUM aggregate is calculated for real (float4) type using
floating point accumulator?
It cause very confusing and unexpected behavior:
-- postgres=# select sum(l_quantity) from lineitem where l_shipdate <=
'1998-12-01';
sum
-
1.52688e+09
(1 row)
On Mon, Feb 13, 2017 at 10:52 AM, Peter Eisentraut
wrote:
> People have all kinds of expectations on how the build system behaves.
> It's not just ./configure; make; make install. All kinds of niche and
> edge cases have evolved over the years. Variables you
>
> I wasn't too happy with the extra param, either. Having moved the guts to
>> conditional.c, I'm happy with that change and can move the stack head back
>> to scan_state with a clear conscience.
>>
>
>
That effort was creating as many headaches as it solved. Rolled back v12
except for doc
On 02/13/2017 11:00 AM, Robert Haas wrote:
> My big objection to removing these views is that it will break pgAdmin
> 3, which uses all three of these views. I understand that the pgAdmin
> community is now moving away from pgAdmin 3 and toward pgAdmin 4, but
> I bet that pgAdmin 3 still has
Robert Haas wrote:
> My big objection to removing these views is that it will break pgAdmin
> 3, which uses all three of these views. I understand that the pgAdmin
> community is now moving away from pgAdmin 3 and toward pgAdmin 4, but
> I bet that pgAdmin 3 still has significant usage and will
On Thu, Feb 9, 2017 at 8:54 PM, Stephen Frost wrote:
> Note that these views have not been consistently maintained and have
> ended up including some role attributes from recent versions
That's not a bug. According to the documentation, these views exist
for compatibility
On 02/13/2017 03:16 PM, Bernd Helmle wrote:
Am Samstag, den 11.02.2017, 15:42 +0300 schrieb Alexander Korotkov:
Thus, I see reasons why in your tests absolute results are lower than
in my
previous tests.
1. You use 28 physical cores while I was using 32 physical cores.
2. You run tests in
On Sat, Feb 11, 2017 at 1:41 AM, Dilip Kumar wrote:
> I tried my best, please check the latest patch (0001).
I don't think it's acceptable (or necessary) to move the DSA
definitions into postgres.h. Why do you think you need to do that,
vs. just including dsa.h in a few
Am Samstag, den 11.02.2017, 00:28 +0100 schrieb Tomas Vondra:
> Comparing averages of tps, measured on 5 runs (each 5 minutes long),
> the
> difference between master and patched master is usually within 2%,
> which
> is pretty much within noise.
>
> I'm attaching spreadsheets with summary of
On Mon, Feb 13, 2017 at 3:09 AM, Jim Nasby wrote:
> On 2/7/17 9:16 AM, Daniele Varrazzo wrote:
>>
>> Thank you for the clarification: I will assume the behaviour cannot be
>> maintained on PG 10 and think whether the treatment of '{}' is too
>> magical and drop it
On Mon, Feb 6, 2017 at 11:06 AM, Amit Khandekar wrote:
> Ashutosh Bapat wrote:
>>> We may want to think about a third goal: preventing too many workers
>>> from executing the same plan. As per comment in get_parallel_divisor()
>>> we do
On Mon, Feb 13, 2017 at 6:24 PM, Robert Haas wrote:
> I don't think it's acceptable (or necessary) to move the DSA
> definitions into postgres.h. Why do you think you need to do that,
> vs. just including dsa.h in a few more places?
I need to access dsa_pointer in
On 2017-02-11 11:16, Erik Rijkers wrote:
On 2017-02-08 23:25, Petr Jelinek wrote:
0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch
0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch
0003-Fix-after-trigger-execution-in-logical-replication-v2.patch
101 - 114 of 114 matches
Mail list logo