as well (no
> break and re-acquire when scrolling in a new page).
Hmm, indenting the descriptions a couple more spaces might be a workable
compromise. Anyone want to try that and see what it looks like?
Preferably somebody who's not happy with the current layout ;-)
stion right now,
but as far as the testing goes, there's already precedent for filtering
EXPLAIN output --- see explain_sq_limit() in subselect.sql. But I'm
dubious whether the rowcount estimate could be relied on to be perfectly
machine-independent, even if you were hiding costs successfully.
Andres Freund writes:
> Indeed that seems plausible. I guess something like the attached should
> fix the issue?
Ah, I see you came to the same conclusion I did. But see comment
about adding a comment.
regards, tom lane
--
Sent via pgsql-hackers mailing list
d use adjustment).
Andres?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
be that should happen.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Kuntal Ghosh writes:
> On Tue, Sep 12, 2017 at 9:47 PM, Tom Lane wrote:
>> Aleksander Alekseev writes:
>>> The following review has been posted through the commitfest application:
>>> make installcheck-world: tested, passed
>>> Implements feature:
ns.
This proposes to make the vertical space nearly triple what it was in v10.
In a typical-size window that's going to have a pretty severe impact on
how much of the list you can see at once. And the readability gain is
(at least to my eyes) very marginal.
regards,
e for pd_lower on that page. This has to be coped with.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
> Attached is a patch series that allows us to create arrays of domain
> types.
Here's a rebased-up-to-HEAD version of this patch set. The only
actual change is removal of a no-longer-needed hunk in pl_exec.c.
regards, tom lane
diff --git a/
Thomas Munro writes:
> On Wed, Sep 13, 2017 at 2:34 AM, Alvaro Herrera
> wrote:
>> Tom Lane wrote:
>>> Can you clarify what went wrong for you on that one? I went to rebase it,
>>> but I end up with the identical patch except for a few line-numbering
>&
-error cases, because
it turns out that PQcmdTuples() is not an amazingly cheap function.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Chapman Flack writes:
> On 09/12/2017 03:41 PM, Tom Lane wrote:
>> So the conclusion at the end of the last commitfest was that this patch
>> should be marked Returned With Feedback, and no new work appears to have
>> been done on it since then. Why is it in this fest at all
[ changing subject line to possibly draw more attention ]
Mark Dilger writes:
>> On Apr 5, 2017, at 9:23 AM, Tom Lane wrote:
>> In short, if you are supposed to write
>> FOO *val = PG_GETARG_FOO(n);
>> then the macro designer blew it, because the name implies tha
at that will break all four options,
it's not very obvious why not.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
again.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
It could be as simple as putting the check-for-done at the bottom of the
loop not the top, perhaps.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
get a SQLSTATE from the PGresult, it should just set the
sqlstate variables to empty strings.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas writes:
> On Tue, Sep 12, 2017 at 1:37 PM, Tom Lane wrote:
>> The trick here is that I don't think we want to change the returned column
>> types for queries that are not being sent to a client. The parser and
>> planner aren't really aware of that co
at
to me. Especially when you've not provided any hard evidence as to why
the current lack-of-information is useful.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
per thread, I'd rather the test not assume that.
I would not necessarily object to doing something in the code that
would guarantee that, though.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
hat we'll never
have any built-in domains just to support such a crock as this.
> 1. Revisit the decision to smash domain types to base types here.
> That change was made by Tom Lane back in 2003
> (d9b679c13a820eb7b464a1eeb1f177c3fea13ece) but the commit message only
> says *that*
h to start up that it doesn't get to run
any transactions? IOW, do we need to allow 0 to 3 lines?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tween two PG major releases. Only
if your patch doesn't get in by v11 freeze would you need to make it a
separate citext--1.5--1.6.sql script.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Also I didn't manage to find any typos or obvious mistakes in the code.
Thanks for reviewing! I assume this is against the prior version of the
patch, though, not the one I just posted with updates for contrib.
Do you want to look at those?
regards, tom lane
--
to run at most 2. Is this a pgbench bug, or is the test
being overoptimistic about how exact the "-T 2" cutoff is?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
Robert Haas writes:
> On Tue, Sep 12, 2017 at 9:58 AM, Alvaro Herrera
> wrote:
>> Did anything happen on this, or did we just forget it completely?
> I forgot it. :-(
> I really think we should fix this.
+1. You've got the rest of the week ...
g pg_stat_activity is a lot more common
> than reading it.
+1. I kinda doubt that it is worth optimizing further than that,
really.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera writes:
> Tom Lane wrote:
>> Aleksander Alekseev writes:
>>> === Apply Failed: 29 ===
>>> https://commitfest.postgresql.org/14/1235/ (Support arrays over domain
>>> types)
>> Can you clarify what went wrong for you on that one? I w
Here's an updated version of this patch that is rebased against HEAD
(no changes there except line numbers) and adds the necessary updates
for contrib.
I'd like to get this committed fairly soon before it bit-rots.
Anyone want to review it?
regards, tom lane
di
gresql.org/14/1235/ (Support arrays over domain types)
Can you clarify what went wrong for you on that one? I went to rebase it,
but I end up with the identical patch except for a few line-numbering
variations.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql
oads.
This patch no longer applies cleanly on HEAD, so here's a rebased version
(no substantive changes). As before, I think the most useful review task
would be to quantify whether it makes planning noticeably slower.
regards, tom lane
diff --git a/src/backend/opti
Jim Nasby writes:
> I've verified that the patch still applies and make check-world is clean.
Not any more :-(. Here's a v3 rebased over HEAD. No substantive
change from v2.
regards, tom lane
diff --git a/src/backend/nodes/outfuncs.c b/src/backend/nod
Michael Paquier writes:
> On Mon, Sep 11, 2017 at 11:55 PM, Tom Lane wrote:
>> Hm, I don't much like having it silently ignore files that are present;
>> that seems like a foot-gun in the long run. What do you think of the
>> attached?
> That looks good to me. I ha
t see this pushed to the repo?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On 11 September 2017 at 23:19, Tom Lane wrote:
>> Uh, what? Sure you can. Just because the existing code never has a
>> reason to create such a dependency doesn't mean it wouldn't work.
> Well, I thought th
x
ends up being.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ode never has a
reason to create such a dependency doesn't mean it wouldn't work.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that when there are a lot of
arguments, $n is pretty unhelpful. We can always revert this if
we get complaints.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
TE for that
> situation where libpq did not report an error?
Meh. If we're going to do that I think it might be better to hack
libpq itself to do so, ie, force PQresultErrorField(..., PG_DIAG_SQLSTATE)
to always return something. But it seems like a hack either way.
Andrew Dunstan writes:
> On 09/08/2017 09:40 AM, Tom Lane wrote:
>> Like you, I'm a bit worried about the code for extracting an exit
>> status from IPC::Run::run. We'll have to keep an eye on the buildfarm
>> for a bit. If there's any trouble, I'd be in
pper-case TRUE/FALSE for the values of ERROR seems a bit
ugly to me; we generally use lower case for other variable values,
so I'd go with true/false.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
Michael Paquier writes:
> On Sun, Sep 10, 2017 at 12:38 AM, Tom Lane wrote:
>> The specific case we need to allow is "ENOENT on a file/dir that was
>> there a moment ago". I think it still behooves us to complain about
>> anything else. If you think it's a s
.. IN ... syntax proposal might be better from that
standpoint.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
hat it had
to be in read-write storage.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ight help narrow things down.
Offhand my bet is on mysql_fdw needing an update for some PG10
change, but that's just a guess.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
s have
ECC memory, though. Race condition against some updater? But the file
is only 512 bytes, and we've always assumed that that size of disk
read or write is atomic. (Platform is RHEL6/x86_64, kernel is
Red Hat 2.6.32-696.10.1.el6.x86_64.)
regards, tom lane
--
Sent
e performance.) Is it worth
adding logic for that? Not sure. It's not like we are actively
changing the RB code or have reason to think it is buggy.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
I'm for using
REGBUF_STANDARD or equivalent for all metapage calls. Even if it
saves no space, inconsistency is bad because it's confusing. And
Michael is correct to point out that we can exploit this to
improve WAL consistency checking.
regards, tom lane
-
options along with their support code, and then drop the portions of
test_rbtree that are needed to exercise them. Any objections?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
ws that a leaf element points to itself.
We could dispense with rb_root(), as well as the test code's knowledge
about RBNIL representation, if we dropped the preorder/postorder cases
... which is another good reason to do so.
regards, tom lane
diff --git a/src/backend/lib/rbt
Michael Paquier writes:
> On Sat, Sep 9, 2017 at 1:43 PM, Tom Lane wrote:
>> Yeah, even if we fixed this particular call site, I'm sure the issue
>> would come up again. Certainly we expect hot backups to work with
>> a changing source directory.
> In
Michael Paquier writes:
> On Fri, Sep 8, 2017 at 5:24 AM, Tom Lane wrote:
>> In short, this patch needs a significant rewrite, and more analysis than
>> you've done so far on whether there's actually any benefit to be gained.
>> It might not be worth messing with
Michael Paquier writes:
> On Sat, Sep 9, 2017 at 11:32 AM, Tom Lane wrote:
>> In a moment of idleness I tried to run the TAP tests on pademelon,
>> which is a mighty old and slow machine.
> How long did it take?
The last time I tried it, make check-world took about 3 hours II
cursiveCopy" or "we need to fix the callers to not call RecursiveCopy
until the source directory is stable". Thoughts?
(I do kinda wonder why we rolled our own RecursiveCopy; surely there's
a better implementation in CPAN?)
regards, tom lane
--
Sent via pgsql-
hat that's not a significant
difference. It's also much less ugly if you decide you need one more
line than the English version uses.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
eir notions of statement blocks all differ from whatever we might
think that is at the interactive-SQL-command level.
(2) AIUI the feature request is specifically for a single-statement
variable change, not any larger scope than that.
regards, tom lane
--
Sent via pgsql-hac
the statement. But this
proposal would break that. We need to put FOR or IN or another
already-fully-reserved keyword after the SET list, or something's going
to bite us.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Bruce Momjian writes:
> On Wed, Jul 19, 2017 at 12:39:07PM -0400, Tom Lane wrote:
>> Yeah, I see nothing about 3f902354b in release-10.sgml either.
>> We've had varying policies over the years about whether to mention
>> internal API changes in the release notes or no
be; but now that we're actually
documenting how to script multi-command queries, it might be
a good idea to fix it before too many people have scripts that
rely on the current behavior.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
see subject.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, I'd be inclined to drop it down
to just success/fail rather than checking the exact exit code.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
simpler in the long run to just have three or four totally independent
sections of the config file, instead of some common and some library-
specific parameters.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs writes:
> On 7 September 2017 at 11:31, Tom Lane wrote:
>> Haas' idea of some kind of syntactic extension, like "LET guc1 = x,
>> guc2 = y FOR statement" seems more feasible to me. I'm not necessarily
>> wedded to that particular syntax, bu
Simon Riggs writes:
> On 7 September 2017 at 11:24, Tom Lane wrote:
>> Not hearing anything, I already pushed my patch an hour or three ago.
> Yes, I saw. Are you saying that doc commit is all we need? ISTM we
> still had an actual bug.
The originally reported bug is fixed.
I wrote:
> Dmitriy Sarafannikov writes:
>> [ snapshot_non_vacuumable_v3.patch ]
> In short I think we should just set up the threshold as RecentGlobalXmin.
Pushed with that adjustment and some fooling with the comments.
regards, tom lane
--
Sent via p
x27;m inclined not to fuss about it. We could arrange for
HeapTupleSatisfiesNonVacuumable to use RecentGlobalXmin directly,
but that seems like it makes it too special-purpose.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
te, and more analysis than
you've done so far on whether there's actually any benefit to be gained.
It might not be worth messing with.
I'll set the CF entry back to Waiting on Author.
regards, tom lane
--
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 writes:
> On 9/5/17 15:32, Tom Lane wrote:
>> I do agree with the idea that we should use the * notation in cases where
>> the reader might otherwise think that a plain function was being invoked,
>> ie I don't like
>> some_function_pointer(args
;t provide that
result either.
Haas' idea of some kind of syntactic extension, like "LET guc1 = x,
guc2 = y FOR statement" seems more feasible to me. I'm not necessarily
wedded to that particular syntax, but I think it has to look like
a single-statement construct of some kind.
Simon Riggs writes:
> On 5 September 2017 at 10:22, Tom Lane wrote:
>> Does anyone want to do further review on this patch? If so, I'll
>> set the CF entry back to "Needs Review".
> OK, I'll review Michael's patch (and confirm my patch is dead)
Not
865adc
Feel free to suggest improvements.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e anything in ecpg, IMO.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On 31 August 2017 at 14:49, Tom Lane wrote:
>> pgbench with log_statement = all would be a pretty easy test case.
> It seems that for this particular workload it was about 20-25% slower.
Ouch. That seems like rather a large
Catalin Iacob writes:
> On Mon, Sep 4, 2017 at 4:15 PM, Tom Lane wrote:
>> Also, the main thing that we need xact.c's involvement for in the first
>> place is the fact that implicit transaction blocks, unlike regular ones,
>> auto-cancel on an error, leaving you ou
Michael Paquier writes:
> On Thu, Sep 7, 2017 at 5:49 AM, Tom Lane wrote:
>> I looked briefly at these patches. I'm not sure that it's safe for the
>> mask functions to assume that meta pages always have valid pd_lower.
>> What happens when replaying log da
de can allow. We use that same limit for timestamps when
* using floating-point timestamps ... For integer timestamps, the upper
* limit is 294276-12-31.
I would hope that any timestamps you've got beyond 294276AD are erroneous
data that you need to clean up anyway.
d how about insertion of already-existing keys? Although that's
a bit outside the scope of testing traversal, so if you want to leave
it for some future expansion, that'd be OK.
I'll set this back to Waiting on Author. I do encourage you to finish
it up.
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)
T
-guidelines
Usually we just use two independent messages, and that's what I did.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
space.
I looked briefly at these patches. I'm not sure that it's safe for the
mask functions to assume that meta pages always have valid pd_lower.
What happens when replaying log data concerning an old index that doesn't
have that field filled?
regards, tom lane
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 surv
ange to pg_atomic_read_u32_impl and
pg_atomic_read_u64_impl, and recompiled. I get bit-for-bit the
same backend executable. Maybe it would have an effect on some
other compiler, but I doubt it, except perhaps at -O0.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pg
ather paths until
> after we've applied the target list (and the associated costing
> changes) to both the regular path list and the partial path list.
Might be a tad messy to rearrange things that way.
regards, tom lane
--
Sent via pgsql-hackers mailing list
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 t
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_atomi
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 exac
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_ w
#x27;t think "yes, it really works" is a helpful use of documentation
space.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e_u64_impl to be
different from the rest, it needs to have a comment explaining why.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
f
the cost estimates.
> I'd feel a lot happier if Tom were to decide how this ought to be
> fixed, because - in spite of some modifications by various parallel
> query code - this is basically all his design and mostly his code.
I can take a look, but not right away.
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
-
cture, because tweaks there are likely to buy
much more.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
PQserverVersion worked correctly
for ancient server versions back then than we need be today.)
> * Clarification to avoid confusion between VERSION and SERVER_VERSION
In what way are these variables not adequately specified already?
regards, tom lane
--
Sent via pgsql-h
ove that the return
value is not needed. It's not clear that that could apply in any
of these uses of pg_atomic_compare_exchange_u32_impl, though.
In any case, by my own argument, it shouldn't matter, because if
any of these are really performance-critical then we should be
looking for be
e GUC(s) would be consulted when retrieving plans from the cache,
and changes in their values from one retrieval to the next might
cause funny behavior. Maybe the relevant settings need to be captured
when the plancache entry is made ... not sure.
regards, tom lane
--
Sent vi
are
> enabled, which should be enough to trigger the rewritten test, no?
I think Peter's on about the Windows case. Not sure how that's handled,
but it's not "make check".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hack
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.
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 attentio
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 subscripti
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
401 - 500 of 48047 matches
Mail list logo