decide to go that direction, though.
FYI, doc/src/sgml/README.links has instructions on how these markup
elements behave, or at least used to behave. We need to update that
file if it changed.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Mon, Jan 9, 2017 at 04:52:46PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Mon, Jan 9, 2017 at 01:34:03PM -0500, Robert Haas wrote:
> > > On Fri, Jan 6, 2017 at 7:29 PM, Peter Eisentraut
> > > <peter.eisentr...@2ndquadrant.com> wrote:
> >
ds.
I assume it is to match our use of CURRENT_USER as having special
meaning.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancien
t is a missing feature, i.e.:
https://wiki.postgresql.org/wiki/Todo#Administration
Have custom variables be transaction-safe
https://www.postgresql.org/message-id/4b577e9f.8000...@dunslane.net
--
Bruce Momjian <br...@momjian.us>http://momjian
/a/218295 should be an easy change to make (though
> perhaps with a variable that gives you the old behavior).
Please src/tools/pgtest for an example of pulling out warning lines and
reporting them at the end of the build.
--
Bruce Momjian <br...@momjian.us>
> This can be easily enhanced with pluggable storage methods once they are
> available.
Have you see this post from 2015:
https://www.postgresql.org/message-id/20150831225328.GM2912%40alvherre.pgsql
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
getting those values via polling.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
Sent via
changes like this, our API becomes nonintuitive very
quickly, and let's face it, we expose a lot of internal interfaces to
our users, so clarity is extra important.
I don't think anyone is arguing that these API breakages are cost-free,
but I think long-term, the costs are minor compared to the
ecosystem, and we might even have more of it.
This basically pushes the quoting overhead from users moving to Postgres
from other databases to Postgres ecosystem tooling. Whether that is
better or worse overall is a judgement call, as Robert stated.
--
Bruce Momjian <br...@momjian.us>
On Thu, Jan 5, 2017 at 06:48:17PM -1000, Joel Jacobson wrote:
> On Thu, Jan 5, 2017 at 4:59 PM, Bruce Momjian <br...@momjian.us> wrote:
> > Agreed. No need in adding overhead for short-lived locks because the
> > milli-second values are going to be meaningless to users.
e is
> one being done, but I'm not sure how accessible its result is.)
Agreed. No need in adding overhead for short-lived locks because the
milli-second values are going to be meaningless to users. I would be
happy if we could find some weasel value for non-heavyweight locks.
--
Bruce Mo
certain cases.
I still question the value of this patch as it requires user
configuration vs. more aggressive HOT/WARM updates.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I a
ly more. I
> think his commit sscripts are badly broken.
>
> I've pushed a reset to the master repo. Working on the mirror now.
Yeah, I was doing parallel pulls of different branches in git via shell
script, and it seems the size of this commit showed me that doesn't
work. Sorry
---
>
> //Magnus
>
>
> On Tue, Jan 3, 2017 at 6:41 PM, Bruce Momjian <br...@momjian.us> wrote:
>
>
> Sorry, this will be reverted and redone.
>
>
> -------
>
alysis by me, patch by Antonin Houska
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
Se
al to have a sub-document underneath each major release note
section with more detailed instructions. This could be done for minor
releases as well where necessary.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprised
whatever we do, we place the information in a permanent
> location that isn't moved or removed.
>
>
>
> +1. Absolutely. That's a very important point.
That is really my only point --- wherever you put it, expect it to live
there forever.
--
Bruce Momjian <br
into another section that we keep around (whether as part of the release
> notes,
> or as a separate "upgrade steps" section or something).
I suggest whatever we do, we place the information in a permanent
location that isn't moved or removed.
--
Bruce Momjian <br...@mom
On Sat, Dec 17, 2016 at 07:38:46PM -0500, Bruce Momjian wrote:
> As Andres already stated, the problem is that there is a text/plain and
> text/html of the same email, and the diff is _inside_ the multipa/mixed
> HTML block. I think it needs to be outside on its own.
Mutt shows t
On Sat, Dec 17, 2016 at 03:47:34PM -0800, Andres Freund wrote:
> On 2016-12-17 15:30:08 -0800, David Fetter wrote:
> > On Sat, Dec 17, 2016 at 05:54:04PM -0500, Bruce Momjian wrote:
> > > On Sun, Dec 18, 2016 at 07:41:50AM +0900, Michael Paquier wrote:
> > > > O
On Sun, Dec 18, 2016 at 07:41:50AM +0900, Michael Paquier wrote:
> On Sun, Dec 18, 2016 at 6:42 AM, Bruce Momjian <br...@momjian.us> wrote:
> > Uh, did you mean to attached patch here?
>
> Strange. I can confirm that I have received the patch as attached, but
> it is not o
am fine putting this as a subsection of the release notes, but
let's not pretend it is some extra section we can remove in five years.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ A
leting
> entries in that
> list if redo process faced commit/abort. In case of checkpoint or end of
> recovery
> transactions remaining in that list are dumped to files in pg_twophase.
>
> Seems that current approach is way more simpler and patch has two times less
> LOCs then p
ostgres 10, i.e.
this is not quality documentation for someone going from Postgres 10 to
Postgres 11.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will
On Fri, Dec 16, 2016 at 07:19:43PM -0500, Robert Haas wrote:
> On Fri, Dec 16, 2016 at 5:29 PM, Bruce Momjian <br...@momjian.us> wrote:
> > I am fine with the release note, or the release notes plus a link to a
> > wiki, like we have done in the past with complex fixes
On Thu, Dec 15, 2016 at 04:16:36PM -0800, Josh Berkus wrote:
> On 12/15/2016 12:54 PM, Tom Lane wrote:
> > Magnus Hagander <mag...@hagander.net> writes:
> >> On Thu, Dec 15, 2016 at 1:11 AM, Bruce Momjian <br...@momjian.us> wrote:
> >>> You are saying thi
ly can't optimize that while keeping a reasonable maintenance
burden.
This is where JIT and LLVM help. I outlined two external projects that
were researching this in this blog entry:
http://momjian.us/main/blogs/pgblog/2016.html#April_1_2016
I am excited to now be seeing WIP code.
--
On Wed, Dec 14, 2016 at 02:29:07PM -0800, Josh Berkus wrote:
> On 12/14/2016 08:06 AM, Bruce Momjian wrote:
> > On Fri, Dec 9, 2016 at 09:46:44AM +0900, Michael Paquier wrote:
> >>>> My own take on it is that the release notes are already a massive
> >>>>
recommended 'password' for SSL connections because if you
use MD5 passwords the password text layout is known and that simplifies
cryptanalysis.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so on
a per-version information, that seems adapted to me. There
> could be as well in the release notes a link to the portion of the
> docs holding this manual. Definitely this should be self-contained in
> the docs, and not mention the wiki. My 2c.
Yes, that is the usual approach.
--
Do you also this as a problem or am I missing something? If this a
> problem, then I think we need some form of delete marking system for
> the index, probably transaction visibility information as well.
Yes, very similar to the problems with WARM already discussed.
--
Bruce Momjian
ng that is holding back more aggressive
WARM updates.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave insc
writing my MVCC talk is that no matter how
much we optimize UPDATE, we still need cleanup for deletes and aborted
transactions.
I am hopeful we can continue reducing the number of times we write a
page for maintenance purposes.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
Enter
On Thu, Nov 24, 2016 at 10:13:30AM +0100, Magnus Hagander wrote:
> On Thu, Nov 24, 2016 at 2:26 AM, Bruce Momjian <br...@momjian.us> wrote:
>
> On Mon, Nov 14, 2016 at 08:43:12PM +, Greg Stark wrote:
> > That said, I don't think the "maintain clustering a bit
nd
double caching methods, and when to recommend one over the other. Seems
UNDO would have the same complexity.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you
e used BRIN to find heap pages where the new row was in the
page BRIN min/max range, and the heap page had free space. Only if that
fails do we put is somewhere else in the heap.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://e
On Tue, Oct 25, 2016 at 01:19:26PM -0400, Robert Haas wrote:
> On Tue, Oct 25, 2016 at 11:20 AM, Bruce Momjian <br...@momjian.us> wrote:
> > Do we still need to report the wraparound warning on server startup?
> >
> > LOG: MultiXact member wraparound protection
On Sat, Oct 22, 2016 at 11:39:40AM -0400, Bruce Momjian wrote:
> I found our postgresql.conf and pg_hba.conf config files had
> inconsistent comment instructions about reloading, and didn't mention
> SELECT pg_reload_conf().
>
> The attached doc patch fixes this.
Patch
Do we still need to report the wraparound warning on server startup?
LOG: MultiXact member wraparound protections are now enabled
I thought that was going to be removed at some point, no?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
Enterp
ndent about that, and I dunno how hard that is.
I think it would be easy to teach pg_indent.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+
On Mon, Oct 24, 2016 at 11:59:42AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Sat, Oct 22, 2016 at 11:18:28PM +0300, Greg Stark wrote:
>
> > > I think the apt-get behaviour was specifically designed to ensure it
> > > couldn't easily be put into a
gres
> database scripts need to do a resetxlog. I'm not sure I can think of
> any examples offhand but I wouldn't be too surprised.
Yes, pg_upgrade has eight calls to pg_resetxlog to set various value.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
Enterpris
>
> > I'm +1 on pg_clog -> pg_xact.
>
> So let's say that's the winner then.
>
> > Also +1 to renaming pg_subtrans to pg_subxact.
>
> Nice suggestion, good naming for consistency with the rest.
Agreed.
--
Bruce Momjian <br...@momjian.us>
I found our postgresql.conf and pg_hba.conf config files had
inconsistent comment instructions about reloading, and didn't mention
SELECT pg_reload_conf().
The attached doc patch fixes this.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
Enterp
On Fri, Oct 21, 2016 at 10:44:41AM -0400, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > Why is autovacuum_freeze_max_age's default set to 200 million, rather
> > than something like 2 billion? It seems 2 billion is half way to
> > wrap-around and would
be trimmed? Is that
reasonable? We have tuple status flags of commit status so I assume
changing from a normal xid to a frozen one doesn't have a performance
benefit, does it?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Thu, Oct 20, 2016 at 02:02:27PM -0400, Robert Haas wrote:
> On Thu, Oct 20, 2016 at 1:39 PM, Bruce Momjian <br...@momjian.us> wrote:
> > On Thu, Oct 20, 2016 at 12:29:47PM -0400, Robert Haas wrote:
> >> > When it comes to the name, I tend to think of 'pg_xact' as sayi
be a
> little bit deliberately unclear, but "xact" for "transaction" is not a
> lot better than "xlog" for "write-ahead log". It's just arbitrary
> abbreviations we made up and you either know what they mean or you
> don't. We could call it &
erformance problem by 50% even if
> she needs to think about the solution a bit.
>
> WARM can do WARM update 50% of time, indirect index can do HOT update
> 100% of time (provided the column is not changed), I don't see why we
> could not have both solutions.
We don't know enou
On Thu, Oct 20, 2016 at 10:39:23AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > Just to clarify, if a feature improves performance by 1%, but is enabled
> > by default, that is 10x more useful across our entire user base as the
> > feature numbers listed above
On Wed, Oct 19, 2016 at 01:04:16PM -0400, Bruce Momjian wrote:
> On Wed, Oct 19, 2016 at 06:58:05PM +0200, Simon Riggs wrote:
> > >> I agree. Also, I think the recheck mechanism will have to be something
> > >> like
> > >> what I wrote for WARM i.e. only c
On Wed, Oct 19, 2016 at 08:17:46PM -0400, Robert Haas wrote:
> On Wed, Oct 19, 2016 at 12:59 PM, Bruce Momjian <br...@momjian.us> wrote:
> > Uh, vacuum_defer_cleanup_age sets an upper limit on how long, in terms
> > of xids, that a standby query can ru
> makes no sense to say how we are using 'int' rather than 'pgsocket'
> when in fact we are not using 'int' any more.
Agreed.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ A
On Wed, Oct 19, 2016 at 01:25:33PM -0400, Tom Lane wrote:
> Bruce Momjian <br...@momjian.us> writes:
> > On Wed, Oct 19, 2016 at 09:44:05AM -0700, David G. Johnston wrote:
> >> I think the theory of having all system tables except LO on SSD storage,
> >> and
&g
On Wed, Oct 19, 2016 at 09:44:05AM -0700, David G. Johnston wrote:
> On Wed, Oct 19, 2016 at 9:29 AM, Bruce Momjian <br...@momjian.us> wrote:
>
> On Tue, Oct 18, 2016 at 04:51:54PM +0200, Andreas Joseph Krogh wrote:
> > > 2. Being able to move pg_largeobject t
, and a background process to clean things up from
an abandoned server.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient
es.
>
> So everybody please chirp in with benefits or comparisons.
I am not sure we have even explored all the limits of WARM with btree
indexes --- I haven't heard anyone talk about non-btree indexes yet.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
Enterpris
On Wed, Oct 19, 2016 at 09:00:06AM -0400, Robert Haas wrote:
> On Wed, Oct 19, 2016 at 8:47 AM, Bruce Momjian <br...@momjian.us> wrote:
> > On Wed, Oct 19, 2016 at 08:33:20AM -0400, Robert Haas wrote:
> >> On Tue, Oct 18, 2016 at 4:33 PM, Josh Berkus <j...@agliod
On Wed, Oct 19, 2016 at 06:33:55PM +0200, Andreas Joseph Krogh wrote:
> På onsdag 19. oktober 2016 kl. 18:29:31, skrev Bruce Momjian <br...@momjian.us
> >:
>
> On Tue, Oct 18, 2016 at 04:51:54PM +0200, Andreas Joseph Krogh wrote:
> > > 2. Being
re that requires a DBA to evaluate and enable it.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription
pg_upgrade was not popular at the time that thread was started.
I think an open question is why you would not want to move the other
system tables at the same time you move pg_largeobject.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
On Wed, Oct 19, 2016 at 11:08:28AM -0500, Kevin Grittner wrote:
> On Wed, Oct 19, 2016 at 10:04 AM, Bruce Momjian <br...@momjian.us> wrote:
>
> > Slide 10 of this presentation has an example showing
> > old_snapshot_threshold set to '1min':
> >
> > h
lide 10 of this presentation has an example showing
old_snapshot_threshold set to '1min':
http://momjian.us/main/writings/pgsql/features.pdf
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterp
lf.
> Specifically, this database is mounted on the same volume as the
> operating system (I know, I know) and something non database driven
> sucked up disk space very rapidly and exhausted the volume -- fast
> enough that sar didn't pick it up. Oh well :-) -- thanks for the help
However, disk sp
eshold for standby
servers --- it cancels transactions rather than delaying cleanup.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Anc
re stuck.
If feels like we are going into VARCHAR2 territory where we end up
telling people to use an oddly-named data type forever. Some are
suggesting JSONB is in that category.
I wish I had a suggestion, but I am not above adding trickery to
pg_upgrade to improve the outcome.
--
Bruce
r add a mandatory --rewind-my-data switch.)
I wonder how many of the uses of pg_resetxlog were caused by mistakenly
removing the pg_xlog directory. My point is renaming pg_xlog might
reduce mistake use of pg_resetxlog.
--
Bruce Momjian <br...@momjian.us>http://mo
far
as we did in finding performance bottlenecks before we had this
instrumentation.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ An
nd, but I am not sure how difficult implementation it is. This part
> (COPY input) doesn't support parametrization - and parametrization can have a
> negative performance impact.
And it would need to be \:file_ref in COPY so real data doesn't trigger
it.
--
Bruce Momjian <br...@
w pull the initdb flags out
of a PGDATA and use them.
The good news is that pg_upgrade --check will do the verification and
report any problems, which might be why we have not seems this
complained about before.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
which
> is we can avoid recheck, but not sure if that alone can give us any
> big performance boost. As, you say, it might lead to some
> complication in code, but I think it is worth trying.
>
> Won't it add some requirements for pg_upgrade as well?
Yes, pg_upgrade will mark the
svector('english', 'bookings') @@ 'book <0> booking';
> ?column?
> --
> t
> (1 row)
OK, thanks. I just found it as unusual.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ A
_tsquery('park <3> house');
seems like it would be more logical as <2>, meaning two lexems between
the words.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+
ing while a table is being accessed. I guess we
could drop the lock once we are done with the partition but we don't
currently do that, and it would be complicated.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://en
on't know anything unless you read the source diffs. With
> ICU, you can compare the collation version before and after and at least
> tell the user that they need to refresh indexes or whatever.
Yes, that is a clear win.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
E
ink it makes sense to fix the existing implementation first.
For me, there are several measurements for indexes:
Build time
INSERT / UPDATE overhead
Storage size
Access speed
I am guessing people make conclusions based on their Computer Science
education.
--
Bruce
ust keep using btree like
The big problem is people coming from other databases and assuming our
hash indexes have the same benefits over btree that exist in some other
database software. The 9.5 warning at least helps with that.
--
Bruce Momjian <br...@momjian.us>http://m
explanation of BTScanPosItem and BTScanPosData in
> nbtree.h.
FYI, pg_upgrade has code to easily mark indexes as invalid and create a
script the use can run to recreate the indexes as valid. I have
received no complaints when this was used.
--
Bruce Momjian <br...@momjian.us>
On Tue, Sep 6, 2016 at 10:52:22AM +0900, Amit Langote wrote:
> Attached fixes a typo in header comment in libpq-be.h.
>
> s/libpq_be.h/libpq-be.h/g
Applied.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://e
those temp tables frequently enough to justify
keeping them around for all users.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ An
On Sun, Sep 4, 2016 at 05:30:57PM -0500, Jim Nasby wrote:
> I noticed some imbalanced '-'s in execnodes.h. Though, ISTM newer code
> doesn't use -'s in comments anymore, so maybe it'd be better to just ditch
> them?
Patch applied.
--
Bruce Momjian <br...@momjian.us>ht
ODO list is
> curated. Is there someone whose attention I should direct to this
> thread?
Someone has removed the item. It is a wiki so anyone can add/remove
things.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://e
; sufficient as well.
Couldn't SQL sessions call a PL/Perl function that could query the OS
and set max_parallel_workers_per_gather appropriately?
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you
ar heap flags only after all indexes are
> cleared of duplicate entries and hence a crash in between should not cause any
> correctness issue. As long as heap tuples are marked as warm, amrecheck will
> ensure that only valid tuples are returned to the caller.
OK, got it.
--
Bruce
On Wed, Aug 31, 2016 at 04:03:29PM -0400, Bruce Momjian wrote:
> Why not just remember the tid of chains converted from WARM to HOT, then
> use "amrecheck" on an index entry matching that tid to see if the index
> matches one of the entries in the chain. (It will match al
to
blue in the WARM-to-HOT conversion, and a vacuum crash could lead to
inconsistencies. Consider that you can just call "amrecheck" on the few
chains that have converted from WARM to HOT. I believe this is more
crash-safe too. However, if you have con
estore route. So instead of copying the disk files, issue a
> setval call, and the sequence should be all set up.
>
> Am I missing anything?
Looks straight-forward to me.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http:/
users place pg_xlog on a
different device, so using "wal" would not be clear it was related to
Postgres. Perhaps we can have initdb --xlogdir use pg_wal, and maybe
document this suggestion.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
p
> deadline is a dangerous business. Pushing them without any testing
> is close to irresponsible.
Not being around to fix the breakage after the commit isn't great
either.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://
; That would not be complicated to fix for any tool maintainers.
I agree on a hard break, unless we get pushback from users, and even
then, they can create the symlinks themselves.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http:
> in size.
>
> (This is all about XLOG_SEG_SIZE; I presume XLOG_BLCKSZ can stay as it
> is, right?)
I think having WAL use variable length files would add complexity for
recycling WAL files.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB
ficant performance hits in switching WAL files so they might
be tempted to set very high segment sizes in inappropriate cases.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As
ame pg_xlog and pg_clog directories too.
--
Bruce Momjian <br...@momjian.us>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
--
Sent
On Tue, Aug 23, 2016 at 01:58:02PM -0700, Peter Geoghegan wrote:
> On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian <br...@momjian.us> wrote:
> >> [Windows]
> >> #clients onoff
> >> 12 29793 38169
> >> 24 31587 87237
> >> 48 32
off
> 12 29793 38169
> 24 31587 87237
> 48 32588 83335
> 96 34261 67668
This ranges from a 28% to a 97% speed improvement on Windows! Those are
not typos! This is a game-changer for use of Postgres on Windows for
certain workloads!
--
Bruce Momjian <br.
On Tue, Aug 23, 2016 at 11:35:35AM -0700, Andres Freund wrote:
> On 2016-08-23 14:33:15 -0400, Bruce Momjian wrote:
> > On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> > > On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian <br...@momjian.us> wrote:
> > &
On Tue, Aug 23, 2016 at 02:31:26PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:57 PM, Bruce Momjian <br...@momjian.us> wrote:
> > That's why I was asking you to comment on the final patch, which I am
> > planning to apply to PG 10 soon.
>
> O
On Tue, Aug 23, 2016 at 01:53:25PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:47 PM, Bruce Momjian <br...@momjian.us> wrote:
> >> I have already read the entire thread, and replied only after reading
> >> all messages.
> >
> > Well, what are y
On Tue, Aug 23, 2016 at 01:45:44PM -0400, Robert Haas wrote:
> On Tue, Aug 23, 2016 at 1:43 PM, Bruce Momjian <br...@momjian.us> wrote:
> > On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote:
> >> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian
On Tue, Aug 23, 2016 at 01:30:29PM -0400, Robert Haas wrote:
> On Fri, Jul 29, 2016 at 8:18 PM, Bruce Momjian <br...@momjian.us> wrote:
> > and the units were copied when pg_size_pretty() was implemented. These
> > units are based on the International System of Units (SI
301 - 400 of 16619 matches
Mail list logo
