On Sun, Jun 17, 2018 at 07:23:19PM +0200, Daniel Gustafsson wrote:
> On 17 Jun 2018, at 14:47, Michael Paquier wrote:
>> - if (bms_num_members(clauses_attnums) < 2)
>> + if (bms_membership(clauses_attnums) != BMS_MULTIPLE)
>> For this one, the comment above directly mentions that at least two
On Sat, Jun 30, 2018 at 4:08 AM, Alvaro Herrera
wrote:
> On 2018-Jun-29, Tom Lane wrote:
>
>> Alvaro Herrera writes:
>> > I'm CCing Tom here, as author of the patch that caused (most of) the
>> > issue.
>>
>> Uh ... me? I thought this was a parallel-query issue, which I've
>> pretty much not bee
On Fri, Jun 29, 2018 at 10:39:00PM +0900, Michael Paquier wrote:
> On Fri, Jun 29, 2018 at 08:48:33AM -0400, Robert Haas wrote:
>> Are there other instances of fsync() that also need to be covered?
>
> Yeah, I double-checked the calls to pg_fsync back when I looked at this
> patch, but now that I
Yaroslav writes:
> I've noticed the following in v11 release notes:
> "Window functions now support all options shown in the SQL:2011 standard,
> including RANGE distance PRECEDING/FOLLOWING, GROUPS mode, and frame
> exclusion options"
> But, as far as I see, IGNORE NULLS option for lead, lag, et
Hello.
I've noticed the following in v11 release notes:
"Window functions now support all options shown in the SQL:2011 standard,
including RANGE distance PRECEDING/FOLLOWING, GROUPS mode, and frame
exclusion options"
But, as far as I see, IGNORE NULLS option for lead, lag, etc. is still not
supp
I wrote:
> "Regina Obe" writes:
>> Here is a trivial example to exercise that doesn't involve PostGIS.
>> CREATE TABLE edge AS SELECT 1 AS edge_id;
>> SELECT 't3280', 'L1b' || generate_series(1,10)
>> FROM edge
>> ORDER BY 1;
> That's odd. It works fine in HEAD but not the v10 branch. I suspec
> On Jun 30, 2018, at 2:48 PM, Daniel Gustafsson wrote:
>
>> On 30 Jun 2018, at 20:11, Brad DeJong wrote:
>>
>> I suggest the following edits for the PostgreSQL beta 2 release announcement.
>> I did not provide the edits as a patch because I can't find the source of
>> /about/news/1867.
>
>
> On 30 Jun 2018, at 20:11, Brad DeJong wrote:
>
> I suggest the following edits for the PostgreSQL beta 2 release announcement.
> I did not provide the edits as a patch because I can't find the source of
> /about/news/1867.
The news item is stored in the postgresql.org database, and not in the
Peter Geoghegan writes:
> I think that the argument Tom is making is that it might be useful to
> have statistics on the expression regardless of this -- the expression
> may be interesting in some general sense. For example, one can imagine
> the planner creating a plan with a hash aggregate rath
I suggest the following edits for the PostgreSQL beta 2 release
announcement.
I did not provide the edits as a patch because I can't find the source of
/about/news/1867.
- This release contains ... as well as bug fixes that were reported ...
+ This release contains ... as well as fixes for bugs th
On Fri, Jun 29, 2018 at 1:31 AM, Yugo Nagata wrote:
> I'm sorry but I don't understand why we'd just have to revert this patch
> later.
>
> Do you mean that if we decide to support expressions in included columns in
> future,
> this patch would be reverted? This is wrong. To my understanding, st
On Sat, Jun 9, 2018 at 8:37 PM, Andrew Gierth
wrote:
> I think I got all the issues I currently know of, but there may be
> more, and others may disagree with my classification of issues or the
> rationales for violating the spec. Any feedback?
Related to, but I think distinct from
"Trailing
Tom Lane writes:
> Alvaro Herrera writes:
>>> On 2018-Jun-28, Tom Lane wrote:
According to buildfarm member friarbird, and as confirmed here,
the contrib/test_decoding/specs/oldest_xmin.spec test added by this
commit fails under CLOBBER_CACHE_ALWAYS.
>
>> I suppose 60 seconds (is
On Fri, Jun 29, 2018 at 11:22 PM, Alvaro Herrera
wrote:
> I was a bit surprised by the new epqslot output argument being added,
> and now I think I know why: we already have es_trig_tuple_slot, so
> shouldn't we be using that here instead? Seems like it'd all be simpler ...
>
Hmm, maybe, but not
On 30 June 2018 at 06:47, Srinivas Karthik V
wrote:
> I was using copy command to load. Removing the primary key constraint on
> the table and then loading it helps a lot. In fact, a 400GB table was
> loaded and the primary constraint was added in around 15 hours. Thanks for
> the wonderful sugg
15 matches
Mail list logo
