Applies, compiles, works for me.
Very very minor comments that I should have noticed before, sorry for this
additional round trip.
In the help line, move -I just after -i, to put short options in
alphabetical and decreasing importance order. On this line, also add the
information about the
Hi Everyone,
Since the beginning of September I'm working full-time for EDB. The plan
for now is to continue working at the projects I was working on, in
particular JIT, and to have more time for reviews. I'll be spending the
large majority of my time on community PG.
I'm primarily mentioning it
On Fri, Aug 25, 2017 at 10:46 PM, Robert Haas wrote:
> On Thu, Jul 6, 2017 at 11:35 AM, Ashutosh Bapat
> wrote:
>> If a partitioned table is proven dummy, set_rel_pathlist() doesn't mark the
>> partition relations dummy and thus doesn't set any (dummy) paths in the
>> partition relations. The lac
On Wed, Sep 6, 2017 at 3:58 PM, Tatsuro Yamada
wrote:
> I revised the patch like this:
You should avoid top-posting.
> I didn't change the name of view (pg_stat_progress_cluster) because I'm not
> sure
> whether the new name (pg_stat_progress_reorg) is suitable or not.
Here are some ideas: rewr
I picked this patch for review and started looking at the implementation
details.
Consider the below test:
1)
postgres=# create table foo (a int, b int) partition by list (a);
CREATE TABLE
postgres=# \d foo
Table "public.foo"
Column | Type | Collation | Nullable | Default
---
On Thu, Aug 31, 2017 at 11:23 AM, Peter Eisentraut
wrote:
> A lot of semi-internal code just prints out numeric SPI error codes,
> which is not very helpful. We already have an API function
> SPI_result_code_string() to convert the codes to a string, so here is a
> patch to make more use of that
> When we reviewed the ecpg code,we found the array seem not have the
> end
> character('\0') after using the strncpy function.
True.
> In the function ECPGnoticeReceiver, we use the stncpy function copy
> the
> sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as
> the size
> of
On Tue, Jul 25, 2017 at 9:33 PM, Tomas Vondra
wrote:
> On 7/25/17 12:55 AM, Tom Lane wrote:
>
>> Tomas Vondra writes:
>>
>>> It seems to me that VACUUM and ANALYZE somewhat disagree on what
>>> exactly reltuples means. VACUUM seems to be thinking that reltuples
>>> = live + dead while ANALYZE ap
Hello Tom,
Here is a version 6.
A few thoughts about this patch:
* I think the ERROR_CODE variable should instead be named SQLSTATE.
That is what the SQL standard calls this string, and it's also what
just about all our documentation calls it; see PG_DIAG_SQLSTATE
in libpq, or the SQLSTATE 'x
Hi,
At Mon, 4 Sep 2017 17:17:19 +0900, Michael Paquier
wrote in
> On Mon, Sep 4, 2017 at 4:04 PM, Andres Freund wrote:
> > I've not read through the thread, but this seems like the wrong approach
> > to me. The receiving side should use a correct value, instead of putting
> > this complexity o
Tom Lane wrote:
> "Bossart, Nathan" writes:
> > On 9/4/17, 10:32 PM, "Simon Riggs" wrote:
> >> If we want to keep the code simple we must surely consider whether the
> >> patch has any utility.
>
> > ... I'd argue that this feels like a natural extension of the
> > VACUUM command, one that I, li
Ashutosh Bapat wrote:
> On Wed, Sep 6, 2017 at 1:32 AM, Tom Lane wrote:
> > BTW, I think we *could* use "lfirst_node(List, ...)" in cases where
> > we know the list is supposed to be a list of objects rather than ints
> > or Oids. I didn't do anything about that observation, though.
>
> IMO, it
Here is a version 6.
Small v7 update, sorry for the noise.
Add testing the initial state of all variables.
Fix typos in a comment in tests.
Fix the documentation wrt the current implementation behavior.
--
Fabien.diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
On Wed, Sep 6, 2017 at 1:06 PM, Rushabh Lathia wrote:
>
> 2) Add partition to the foo;
>
> create table foo_p1 partition of foo for values in (1, 2, 3) partition by
> list (b);
>
> postgres=# \d foo
> Table "public.foo"
> Column | Type | Collation | Nullable | Default
> ---
Okay, I have marked this as ready for committer.
Thanks,
On Wed, Sep 6, 2017 at 2:50 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> On Wed, Sep 6, 2017 at 1:06 PM, Rushabh Lathia
> wrote:
> >
> > 2) Add partition to the foo;
> >
> > create table foo_p1 partition of foo for value
Magnus Hagander wrote:
> On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes wrote:
> > Should the parent process of pg_basebackup be made to respond to SIGCHLD?
> > Or call waitpid(bgchild, &status, WNOHANG) in some strategic loop?
>
> I think it's ok to just call waitpid() -- we don't need to react sup
On 2017/09/06 18:46, Rushabh Lathia wrote:
> Okay, I have marked this as ready for committer.
Thanks Ashutosh and Rushabh for rebasing and improving the patch. Looks
good to me too.
Regards,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
On 2017/09/04 10:10, Amit Langote wrote:
> On 2017/09/02 2:52, Robert Haas wrote:
>> It strikes me that this patch set is doing two things but maybe in the
>> opposite order that I would have chosen to attack them. First,
>> there's getting partition pruning to use something other than
>> constrai
> On 06 Sep 2017, at 02:56, Amit Langote wrote:
>
> On 2017/09/05 21:14, Tom Lane wrote:
>> Amit Langote writes:
>>> On 2017/09/05 15:48, Etsuro Fujita wrote:
Here is the copyright in partition.h:
* Copyright (c) 2007-2017, PostgreSQL Global Development Group
I think
On Fri, Jun 2, 2017 at 6:31 PM, Amit Kapila wrote:
>
> Your reasoning sounds sensible to me. I think the other way to attack
> this problem is that we can maintain some local queue in each of the
> workers when the shared memory queue becomes full. Basically, we can
> extend your "Faster process
On Sat, Jul 22, 2017 at 12:05 AM, Alexey Chernyshov
wrote:
> the following patch transfers functionality from gevel module
> (http://www.sai.msu.su/~megera/wiki/Gevel) which provides functions for
> analyzing GIN and GiST indexes to pageinspect. Gevel was originally
> designed by Oleg Bartunov, an
On Sat, Aug 12, 2017 at 1:20 PM, Peter Eisentraut
wrote:
> Here are some small test suites for some contrib modules as well as
> pg_archivecleanup that didn't have one previously, as well as one patch
> to improve code coverage in a module.
>
> Will add to commit fest. Testing on different platfo
On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro
wrote:
>
> Thanks. Bearing all that in mind, I ran through a series of test
> scenarios and discovered that my handling for JOIN_ANTI was wrong: I
> thought that I had to deal with inverting the result, but I now see
> that that's handled elsewhere (c
On 2017-09-06 07:23, Tom Lane wrote:
Jeff Janes writes:
What scale factor and client count? How many cores per socket? It
looks
like Sokolov was just starting to see gains at 200 clients on 72
cores,
using -N transaction.
This means that Sokolov's proposed changes in atomics/generic.h
ought
Michael Meskes writes:
>> In the function ECPGnoticeReceiver, we use the stncpy function copy
>> the
>> sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as
>> the size
>> of 5, and the copy size is sizeof(sqlca->sqlstate). However, from the
>> previous strcmp function, the sqlstate
Hi Ashutosh,
I have tried to address your comments in V27 patch series[1].
Please find my comments inlined.
> >>
> >> The current set of patches contains 6 patches as below:
> >>
> >> 0001:
> >> Refactoring existing ATExecAttachPartition code so that it can be used
> >> for
> >> default partiti
On 2017-09-06 14:54, Sokolov Yura wrote:
On 2017-09-06 07:23, Tom Lane wrote:
Jeff Janes writes:
What scale factor and client count? How many cores per socket? It
looks
like Sokolov was just starting to see gains at 200 clients on 72
cores,
using -N transaction.
This means that Sokolov's p
Michael Paquier writes:
> Fine for 0002. This reminds me of LockGXact and RemoveGXact in
> twophase.c, as well as _hash_squeezebucket that have some code paths
> that cannot return... Any thoughts about having some kind of
> PG_NOTREACHED defined to 0 which could be put in an assertion?
Generally
On 5 September 2017 at 21:23, Tom Lane wrote:
> Jeff Janes writes:
>> What scale factor and client count? How many cores per socket? It looks
>> like Sokolov was just starting to see gains at 200 clients on 72 cores,
>> using -N transaction.
...
> Moreover, it matters which primitive you're tes
On 6 September 2017 at 04:14, Ashutosh Bapat
wrote:
> On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro
> wrote:
>>
>> Thanks. Bearing all that in mind, I ran through a series of test
>> scenarios and discovered that my handling for JOIN_ANTI was wrong: I
>> thought that I had to deal with inverting
Simon Riggs writes:
> On 5 September 2017 at 21:23, Tom Lane wrote:
>> Moreover, it matters which primitive you're testing, on which platform,
>> with which compiler, because we have a couple of layers of atomic ops
>> implementations.
> If there is no gain on 2-socket, at least there is no loss
Simon Riggs writes:
> Why isn't this an open item for PG10?
Why should it be? This behavior has existed for a long time.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql
On 4/14/17 02:00, Michael Paquier wrote:
> Attached is an updated patch to use --no-sync with pg_dumpall calls.
Please send a rebased patch.
I propose splitting the single Perl script into three separate test
files: one for basic command-line option handling and so on (I would
like to expand that
Hi!
I just realized that these lines of contrib/bloom/t/001_wal.pl don't check
that queries give same results on master and standby. They just check that
*return codes* of psql are equal.
# Run test queries and compare their result
> my $master_result = $node_master->psql("postgres", $queries);
On 5 September 2017 at 11:58, Fabien COELHO wrote:
>
> Hello Simon,
>
>> Does raise the further question of how psql behaves when we connect to
>> a pre-10 server, so we have SERVER_VERSION_NUM but yet it is not set.
>> How does this
>> \if SERVER_VERSION_NUM < x
>
>
> The if does not have express
On 2017-09-06 15:56, Tom Lane wrote:
Simon Riggs writes:
On 5 September 2017 at 21:23, Tom Lane wrote:
Moreover, it matters which primitive you're testing, on which
platform,
with which compiler, because we have a couple of layers of atomic ops
implementations.
If there is no gain on 2-so
Sokolov Yura writes:
> On 2017-09-06 15:56, Tom Lane wrote:
>> The point I'm trying to make is that if tweaking generic.h improves
>> performance then it's an indicator of missed cases in the less-generic
>> atomics code, and the latter is where our attention should be focused.
>> I think basicall
Simon Riggs writes:
> Based upon input from Tom and Fabien, I propose this additional doc patch.
I do not think any of this is appropriate, particularly not the reference
to 7.0.3.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 2017-09-06 16:36, Tom Lane wrote:
Sokolov Yura writes:
On 2017-09-06 15:56, Tom Lane wrote:
The point I'm trying to make is that if tweaking generic.h improves
performance then it's an indicator of missed cases in the
less-generic
atomics code, and the latter is where our attention should
Hi!
We're currently blocking writing queries on standby if even they are
modifying contents of foreign tables. But do we have serious reasons for
that?
Keeping in the mind FDW-sharding, making FDW-tables writable from standby
would be good to prevent single-master bottleneck.
I wrote simple patch
I've changed to "need review" to gain more attention from other.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut wrote:
> I propose splitting the single Perl script into three separate test
> files: one for basic command-line option handling and so on (I would
> like to expand that later), one for the main upgrade test, and one for
> the funny database names tests.
Check.
> We also need to
On Wed, Sep 6, 2017 at 4:08 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> I just realized that these lines of contrib/bloom/t/001_wal.pl don't
> check that queries give same results on master and standby. They just
> check that *return codes* of psql are equal.
>
> # Run test queri
On Tue, Sep 5, 2017 at 1:38 PM, Tom Lane wrote:
> The complaint I have about PRAGMA is that it's yet another syntax for
> accomplishing pretty much the same thing. If you don't like the GUC
> solution, we've already got the "comp_option" syntax for static options
> in plpgsql. Sure, that's not t
Alvaro Herrera writes:
> Peter Eisentraut wrote:
>> We also need to have a plan for handling the build farm. Maybe keep the
>> vcregress.pl upgradecheck target as a thin wrapper for the time being?
> The buildfarm already runs "make check" in src/bin/ when TAP tests are
> enabled, which should b
Robert Haas writes:
> I don't think we can just indefinitely continue to resist
> providing manual control over this behavior on the theory that some
> day we'll fix it.
That's fair enough. We need to have a discussion about exactly what
the knob does, which is distinct from the question of how
On Wed, Sep 6, 2017 at 11:03 AM, Tom Lane wrote:
> That's fair enough. We need to have a discussion about exactly what
> the knob does, which is distinct from the question of how you spell
> the incantation for twiddling it. I'm dubious that a dumb "force a
> custom plan" setting is going to sol
On Wed, Sep 6, 2017 at 9:42 AM, Sokolov Yura
wrote:
> Yes, you're right.
>
> But I think, generic version still should be "fixed".
> If generic version is not reached on any platform, then why it is kept?
> If it is reached somewhere, then it should be improved.
This seems like a pretty sound arg
On Tue, Sep 5, 2017 at 10:49 PM, Michael Paquier
wrote:
> On Wed, Sep 6, 2017 at 1:15 AM, Jacob Champion wrote:
>> On Sun, Sep 3, 2017 at 11:14 PM, Michael Paquier
>> wrote:
>>> +#if defined(USE_ASSERT_CHECKING) && !defined(FRONTEND)
>>> +void
>>> +AssertPageIsLockedForLSN(Page page)
>>> +{
>>>
On 6 September 2017 at 06:38, Tom Lane wrote:
> Simon Riggs writes:
>> Based upon input from Tom and Fabien, I propose this additional doc patch.
>
> I do not think any of this is appropriate, particularly not the reference
> to 7.0.3.
OK, no problem.
SERVER_VERSION_NUM is a great new feature.
Robert Haas writes:
> On Wed, Sep 6, 2017 at 9:42 AM, Sokolov Yura
> wrote:
>> But I think, generic version still should be "fixed".
>> If generic version is not reached on any platform, then why it is kept?
>> If it is reached somewhere, then it should be improved.
> This seems like a pretty so
On Wed, Sep 6, 2017 at 12:01 PM, Tom Lane wrote:
>> This seems like a pretty sound argument to me. I think Tom's probably
>> right that the changes in generic-gcc.h are the important ones, but
>> I'm not sure that's an argument against patching generics.h. Given
>> that pg_atomic_compare_exchang
Simon Riggs writes:
> * Clarification that this will work for current AND past server versions
The short answer is it works. I do not think we need a longer answer.
(The existing comment in libpq says that the "select version()" method
works in any server version that supports protocol v2, whic
On Mon, Sep 4, 2017 at 10:52 AM, Amit Khandekar wrote:
> On 4 September 2017 at 07:43, Amit Kapila wrote:
> Oops sorry. Now attached.
I have done some basic testing and initial review of the patch. I
have some comments/doubts. I will continue the review.
+ if (mtstate->operation == CMD_UPDATE
On 8/18/17 05:28, Michael Banck wrote:
>>> Rebased, squashed and slighly edited version attached. I've added this
>>> to the 2017-07 commitfest now as well:
>>>
>>> https://commitfest.postgresql.org/14/1112/
>> Can you rebase this past some conflicting changes?
> Thanks for letting me know, PFA a r
On 1 September 2017 at 22:08, Michael Paquier wrote:
> On Sat, Sep 2, 2017 at 1:53 AM, Robert Haas wrote:
>> On Mon, Aug 21, 2017 at 5:30 PM, Simon Riggs wrote:
>>> Thinking ahead, are we going to add a new --no-objecttype switch every
>>> time someone wants it?
>>
>> I'd personally be fine with
Seeing it as is, it calls for having "SERVER_VERSION" as well, but I'm not
sure of the better way to get it. I tried with "SELECT VERSION() AS
SERVER_VERSION \gset" but varnames are lowerized.
The problem there is you can't get version() without an extra round trip
to the server --- and an ext
On Wed, Sep 6, 2017 at 12:26 PM, Simon Riggs wrote:
>>> I'd personally be fine with --no-whatever for any whatever that might
>>> be a subsidiary property of database objects. We've got
>>> --no-security-labels, --no-tablespaces, --no-owner, and
>>> --no-privileges already, so what's wrong with -
On 4 September 2017 at 10:30, Adrien Nayrat wrote:
> On 09/04/2017 06:16 PM, Alexander Korotkov wrote:
>> Looks good for me. I've integrated those changes in the patch.
>> New revision is attached.
>
> Thanks, I changed status to "ready for commiter".
This looks useful and good to me.
I've chan
Robert Haas writes:
> It's not a question of whether the return value is used, but of
> whether the updated value of *old is used.
Right, but if we re-read "old" in the loop, and if the primitive
doesn't return "old" (or does, but call site ignores it) then in
principle the CAS might be strength-
Simon Riggs writes:
> Other than that, I'm good to commit.
> Any last minute objections?
The docs and comments could stand a bit closer copy-editing by a
native English speaker. Other than that, it seemed sane in a
quick read-through.
regards, tom lane
--
Sent via pgs
On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila wrote:
> Okay, now I understand your point, but I think we already change the
> cost of paths in apply_projection_to_path which is done after add_path
> for top level scan/join paths.
Yeah. I think that's a nasty hack, and I think it's Tom's fault. :-)
On 6 September 2017 at 10:27, Tom Lane wrote:
> Simon Riggs writes:
>> Other than that, I'm good to commit.
>> Any last minute objections?
>
> The docs and comments could stand a bit closer copy-editing by a
> native English speaker. Other than that, it seemed sane in a
> quick read-through.
Wi
Hi Jeff,
On 09/05/2017 03:47 PM, Jeff Janes wrote:
I ran pgbench (-M prepared) with synchronous_commit 'on' and 'off' using
both logged and unlogged tables. Also ran an internal benchmark which
didn't show anything either.
What scale factor and client count? How many cores per socket? It loo
On Tue, Jul 18, 2017 at 5:18 AM, Alexey Chernyshov
wrote:
> Hi all,
Hi Alexey, I took a look at your patch. Builds fine here, and passes
the new tests.
I'm new to this code, so take my review with a grain of salt.
> The attached patch introduces citext_pattern_ops for citext extension type
> li
Robert Haas writes:
> On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila wrote:
>> Okay, now I understand your point, but I think we already change the
>> cost of paths in apply_projection_to_path which is done after add_path
>> for top level scan/join paths.
> Yeah. I think that's a nasty hack, and I
Hello,
* Clarification that this will work for current AND past server versions
The short answer is it works. I do not think we need a longer answer.
To have something operational you have to know quite a bit of psql
details (:-substitutions, backslash command logic, gset, if, quit...).
T
I wrote:
> Anyway, I don't have a big objection to applying this. My concern
> is more that we need to be taking a harder look at other parts of
> the atomics infrastructure, because tweaks there are likely to buy
> much more.
I went ahead and pushed these patches, adding __sync_fetch_and_sub
sin
Fabien COELHO writes:
> Thus short, simple but meaningful examples which show how to do something
> useful with all that in the documentation may help people take advantage
> of these new features.
I don't have an objection to providing an example. I wasn't terribly
impressed with Simon's vers
Hi,
On 2017-09-06 14:31:26 -0400, Tom Lane wrote:
> I wrote:
> > Anyway, I don't have a big objection to applying this. My concern
> > is more that we need to be taking a harder look at other parts of
> > the atomics infrastructure, because tweaks there are likely to buy
> > much more.
>
> I wen
>
>
> I think a GUC is a decent, though not perfect, mechanism for this.
> This problem isn't restricted to PL/pgsql; indeed, the cases I've seen
> have come via prepared queries, not PL/pgsql functions. Even without
> that, one advantage of a GUC is that they are fairly broadly
> understood and e
Thus short, simple but meaningful examples which show how to do something
useful with all that in the documentation may help people take advantage
of these new features.
I don't have an objection to providing an example. I wasn't terribly
impressed with Simon's version, but maybe we can do be
On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila wrote:
>>> Okay, now I understand your point, but I think we already change the
>>> cost of paths in apply_projection_to_path which is done after add_path
>>> for top level scan/j
Andres Freund writes:
> On 2017-09-06 14:31:26 -0400, Tom Lane wrote:
>> However, if that's the reasoning, why don't we make all of these
>> use simple reads? It seems unlikely that a locked read is free.
> We don't really use locked reads? All the _atomic_ wrapper forces is an
> actual read fro
Robert Haas writes:
> On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane wrote:
>> If somebody's applying apply_projection_to_path to a path that's already
>> been add_path'd, that's a violation of the documented restriction.
> /me is confused. Isn't that exactly what grouping_planner() is doing,
> and h
On 2017-09-06 15:12:13 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-09-06 14:31:26 -0400, Tom Lane wrote:
> >> However, if that's the reasoning, why don't we make all of these
> >> use simple reads? It seems unlikely that a locked read is free.
>
> > We don't really use locked read
On 2017-09-06 17:36:02 +0900, Kyotaro HORIGUCHI wrote:
> Hi,
>
> At Mon, 4 Sep 2017 17:17:19 +0900, Michael Paquier
> wrote in
>
> > On Mon, Sep 4, 2017 at 4:04 PM, Andres Freund wrote:
> > > I've not read through the thread, but this seems like the wrong approach
> > > to me. The receiving s
Andres Freund writes:
> On 2017-09-06 15:12:13 -0400, Tom Lane wrote:
>> It looks to me like two of the three implementations promise no such
>> thing.
> They're volatile vars, so why not?
Yeah, but so are the caller's variables. That is, in
pg_atomic_exchange_u64_impl(volatile pg_atomic_uint6
On 2017-09-06 15:25:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2017-09-06 15:12:13 -0400, Tom Lane wrote:
> >> It looks to me like two of the three implementations promise no such
> >> thing.
>
> > They're volatile vars, so why not?
>
> Yeah, but so are the caller's variables. Tha
On Wed, Sep 6, 2017 at 3:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane wrote:
>>> If somebody's applying apply_projection_to_path to a path that's already
>>> been add_path'd, that's a violation of the documented restriction.
>
>> /me is confused. Isn'
Andres Freund writes:
> On 2017-09-06 15:25:20 -0400, Tom Lane wrote:
>> I think we can just use "old = ptr->value" to set up for the cmpxchg
>> loop in every generic.h function that uses such a loop.
> I think we might have been talking past each other - I thought you were
> talking about changi
Robert Haas writes:
> In particular, as Jeff and Amit point out, it
> may well be that (a) before apply_projection_to_path(), the cheapest
> plan is non-parallel and (b) after apply_projection_to_path(), the
> cheapest plan would be a Gather plan, except that it's too late
> because we've already
On Wed, Sep 6, 2017 at 3:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> In particular, as Jeff and Amit point out, it
>> may well be that (a) before apply_projection_to_path(), the cheapest
>> plan is non-parallel and (b) after apply_projection_to_path(), the
>> cheapest plan would be a Gather p
I wrote:
> Ah. I was not thinking of touching pg_atomic_read_u32/u64_impl,
> although now that you mention it, it's not clear to me why we
> couldn't simplify
> - return *(&ptr->value);
> + return ptr->value;
Just to check, I applied that change to pg_atomic_read_u32_impl and
pg_atomic_r
Robert Haas writes:
> On Wed, Sep 6, 2017 at 3:41 PM, Tom Lane wrote:
>> I'm not entirely following. I thought that add_path was set up to treat
>> "can be parallelized" as an independent dimension of merit, so that
>> parallel paths would always survive.
> Here, the Gather path is not parallel
Amit Langote writes:
> On 2017/08/22 9:39, Michael Paquier wrote:
>> On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote
>> wrote:
>>> I updated brin_mask() and spg_mask() in the attached updated patches so
>>> that they consider meta pages as containing unused space.
I looked briefly at these patches
Fabien COELHO writes:
> Here is an attempt at merging some functions which removes 160 lines of
> code.
Pushed with minor adjustments. I thought a couple of variable names
could be better chosen, but mostly, you can't do this sort of thing:
-psql_error("The server (version %s) does
On Fri, Sep 1, 2017 at 6:00 AM, Peter Geoghegan wrote:
> On Wed, Aug 30, 2017 at 4:59 PM, Peter Geoghegan wrote:
>> I may submit the simple patch to remove replacement selection, if
>> other contributors are receptive. Apart from everything else, the
>> "incrementalism" of replacement selection w
Tatsuro Yamada writes:
> The declaration of postgresGetForeignPlan uses baserel, but
> the actual definition uses foreignrel. It would be better to sync.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
On Wed, Sep 6, 2017 at 2:47 PM, Thomas Munro
wrote:
>> I attach a patch to remove replacement selection, which I'll submit to CF 1.
>
> This breaks the documentation build, because
> doc/src/sgml/release-9.6.sgml still contains linkend="guc-replacement-sort-tuples"> but you removed that id.
Than
Hi,
I know I'm 7 months late to this, but only just read the beta 4 release notes.
Is there anything people using float datetimes can do that isn't a
pg_dumpall | pg_restore to do a less painful update?
We have several TB of data still using float datetimes and I'm trying
to figure out how we ca
[ btw, please don't cc pgsql-hackers-owner, the list moderators don't
need the noise ]
Aleksander Alekseev writes:
> I would say that this patch is in a pretty good shape now. And I see a
> 99% code coverage of rbtree.c. Let's see what committers think.
I took a quick look through the patch ---
Omar Kilani writes:
> Is there anything people using float datetimes can do that isn't a
> pg_dumpall | pg_restore to do a less painful update?
Um, not really. You may be stuck on 9.6 until you can spare the effort
to convert. The physical representations of timestamps are totally
different in
On Thu, Sep 7, 2017 at 1:43 AM, Robert Haas wrote:
> On Wed, Sep 6, 2017 at 12:26 PM, Simon Riggs wrote:
I'd personally be fine with --no-whatever for any whatever that might
be a subsidiary property of database objects. We've got
--no-security-labels, --no-tablespaces, --no-owner
On Thu, Sep 7, 2017 at 5:49 AM, Tom Lane wrote:
> Amit Langote writes:
>> On 2017/08/22 9:39, Michael Paquier wrote:
>>> On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote
>>> wrote:
I updated brin_mask() and spg_mask() in the attached updated patches so
that they consider meta pages as con
On 2017/09/07 6:52, Tom Lane wrote:
Tatsuro Yamada writes:
The declaration of postgresGetForeignPlan uses baserel, but
the actual definition uses foreignrel. It would be better to sync.
Pushed, thanks.
regards, tom lane
Thanks!
Regards,
Tatsuro Yamada
--
Sent v
On 9/4/17 06:03, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Michael Paquier writes:
>>> I don't like breaking the abstraction of pg_log() with the existing
>>> flags with some kind of pg_debug() layer. The set of APIs present now
>>> in pg_rewind for logging is nice to have, and I think that those
On Thu, Sep 7, 2017 at 10:11 AM, Peter Eisentraut
wrote:
> On 9/4/17 06:03, Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> Michael Paquier writes:
I don't like breaking the abstraction of pg_log() with the existing
flags with some kind of pg_debug() layer. The set of APIs present now
On Wed, Sep 6, 2017 at 11:44 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Peter Eisentraut wrote:
>>> We also need to have a plan for handling the build farm. Maybe keep the
>>> vcregress.pl upgradecheck target as a thin wrapper for the time being?
>
>> The buildfarm already runs "make check"
On 2017/09/07 8:51, Michael Paquier wrote:
> On Thu, Sep 7, 2017 at 5:49 AM, Tom Lane wrote:
>> Amit Langote writes:
>>> On 2017/08/22 9:39, Michael Paquier wrote:
On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote
wrote:
> I updated brin_mask() and spg_mask() in the attached updated pa
1 - 100 of 120 matches
Mail list logo
