This creative and humorous blog post explains how to make Postgres
slower:
https://byteofdev.com/posts/making-postgres-slow/
This post does not appear on Planet Postgres.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
e curious to understand why EDB BDR is not
> an option?
I agree pgEdge is worth considering:
https://www.pgedge.com/products/pgedge-platform
and perhaps EDB BDR/PGD was not being considered due to cost.
--
Bruce Momjian https://momjian.us
EDB
ee:
https://momjian.us/main/blogs/pgblog/2018.html#December_24_2018
We are working on expanding logical replication to handle DDL changes
and conflicts, but that work is a few years away from completion.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
NSERT_FILE.sql
>
> PSQL is still printing as below.
> INSERT 0 1
> INSERT 0 1
Uh, they should be the same. You can turn on log_statement=all on the
server and look at what queries are being issued in each case.
--
Bruce Momjian https://momjian.us
EDB
e possible that network round trip costs are a big chunk of your
> problem, in which case physically grouping multiple rows into each INSERT
> command (... or COPY ...) is the only way to fix it. But I'd start with
> trying to reduce the transaction commit overhead.
Agreed, turning of
w.postgresql.org/docs/14/performance-tips.html
Your time seems very slow --- are the rows very wide?
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
Desirability -> Design -> Implement -> Test -> Review -> Commit
Not going in this order often leads to backtracking or failure.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
On Fri, Oct 8, 2021 at 05:28:37PM +0200, Thomas Kellerer wrote:
> Bruce Momjian schrieb am 08.10.2021 um 17:21:
> > However, I also need to ask how the wait event information, whether
> > tracing or sampling, can be useful for Postgres because that will drive
> > the s
re needed for wait event, and right
now we really don't have either for wait events --- just the raw
information.
However, I also need to ask how the wait event information, whether
tracing or sampling, can be useful for Postgres because that will drive
the solution.
--
Bruce Momjian
On Thu, Oct 7, 2021 at 10:22:12PM -0700, Jeremy Schneider wrote:
>
> On Oct 7, 2021, at 19:38, Bruce Momjian wrote:
> > Our wait events reported in pg_stat_activity are really only a first
> > step --- I always felt it needed an external tool to efficiently
> > colle
st
step --- I always felt it needed an external tool to efficiently collect
and report those wait events. I don't think the server log is the right
place to collect them.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If o
rocess. On the upside, things that make it into core are usually
> fairly mature.
Jeff, I suggest you consider Laurenz's suggestions above, and try to
ignore the comments from Mladen Gogala, since they are caustic and I
believe unhelpful. Frankly, we rarely have such caustic comments on t
prove the performance?
>
> Thanks a ton in advance for your support.
Uh, there is no query, and I think you should read this:
https://wiki.postgresql.org/wiki/Slow_Query_Questions
--
Bruce Momjian https://momjian.us
EDB https://
oing a dump/restore? I
> assume you would know better than him or me what it actually does do :-)
I think it uses pg_upgrade.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
ite
> up the results.
>
> Also, it's very possible that btfs performs better for (say) report queries,
> but worse for data loading. Maybe you care more about reporting, but that's
> not true for everyone.
My question is whether btrfs is reliable enough or write-durabl
have
been sent to the device, and four are pending to be send to the device,
or at least that is how I understand it. Therefore, I am unclear if
avgqu-sz helps here.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
On Thu, Apr 22, 2021 at 09:54:56PM +0200, Luca Ferrari wrote:
> On Thu, Apr 22, 2021 at 9:52 PM Bruce Momjian wrote:
> >
> > On Thu, Apr 22, 2021 at 09:45:15PM +0200, Luca Ferrari wrote:
> > > Hi all,
> > > I'm unable to find (apparently) a way to find out a
different values of concurrency could help to determine
> the max number of concurrent request, (tps, lower latency, ecc.).
> Is thjs correct or is there another suggested way?
I recommend 256 for SSDs or other RAM-like fsync systems, and maybe
maybe 16 for magnetic.
--
Bruce Momjian
the time from the operating system.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
On Sat, Apr 3, 2021 at 10:41:14AM -0500, Justin Pryzby wrote:
> On Sat, Apr 03, 2021 at 11:39:19AM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Sat, Apr 3, 2021 at 08:38:18PM +0530, aditya desai wrote:
> > >> Yes, force_parallel_mode is on. Should we
On Sat, Apr 3, 2021 at 11:39:19AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sat, Apr 3, 2021 at 08:38:18PM +0530, aditya desai wrote:
> >> Yes, force_parallel_mode is on. Should we set it off?
>
> > Yes. I bet someone set it without reading our
ts this is a Microsoft version of Postgres. I will stop
commenting.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
On Sat, Apr 3, 2021 at 11:12:01AM -0400, Bruce Momjian wrote:
> On Sat, Apr 3, 2021 at 08:38:18PM +0530, aditya desai wrote:
> > Hi Justin,
> > Yes, force_parallel_mode is on. Should we set it off?
>
> Yes. I bet someone set it without reading our docs:
>
>
&
some option in postgresql.conf has very bad
> value.
> > Second - it's crazy to see 200 ms just on interprocess communication -
> > maybe your CPU is overutilized.
>
> It seems like force_parallel_mode is set, which is for debugging and not
> for
>
SELECT version();
SELECT name, current_setting(name), source
FROM pg_settings
WHERE source NOT IN ('default', 'override');
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
If onl
, or
> something like that?
And we have pg_test_timing for gettimeofday() testing.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
parently I
> cannot modify (I suspect this is due to the virtualization of the
> disk):
You should really be running pg_test_fsync for this kind of testing.
--
Bruce Momjian https://momjian.us
EDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
vs writes
2. number of standbys
If you have a high value for #1, it makes sense to use pgpool, but
having only one standby doesn't buy you much; add three, and you will
see an impact. Second, if writes are high, only scaling up the primary
or adding sharding will help you. It is kind of an o
n facility, though you can used the hashed value
rather than the literal password. To encrypt, you would need to decrypt
it and then pass it to libpq, but there is no _pipe_ facility to do
that.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterpri
"Non-sync'ed 8kB writes:" gives non-fsync
performance.
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
hod is _too_ fast,
it might mean that it isn't actually writing to durable storage.
> wal_sync_method or is there any other way?
pg_test_fsync is the only way I know of, which is why I wrote it.
--
Bruce Momjian https://momjian.us
EnterpriseDB http
nc data written on a different
> descriptor.)
> write, fsync, close 445.493 ops/sec2245 usecs/op
> write, close, fsync 448.196 ops/sec2231 usecs/op
>
> Non-sync'ed 8kB writes:
> write
On Fri, Jun 14, 2019 at 10:39:40AM -0400, Bruce Momjian wrote:
> On Fri, Jun 14, 2019 at 03:12:29PM +0200, Fabio Pardi wrote:
> > Using --size-only, tells rsync to only check the size of the blocks.
> > That is: if the block is present on the destination, and is the same
> &g
On Fri, Jun 14, 2019 at 03:12:29PM +0200, Fabio Pardi wrote:
> Hi Bruce,
>
>
> On 6/14/19 5:30 AM, Bruce Momjian wrote:
>
> >> Also, I do not think it best practice (or perhaps not correct at all) to
> >> use '--size-only'
> >
> > --size-
ce (or perhaps not correct at all) to
> use '--size-only'
--size-only is correct, as far as I know.
--
Bruce Momjian 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 +
ing to see if this is true on a supported
version of Postgres.
--
Bruce Momjian 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 +
ended due to fsync
performance.
--
Bruce Momjian 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 +
th pages smaller than a memory
> page, and removing the limitation did not seem very useful compared to
> the added complexity. But it's probably a question for kernel hackers.
My guess is that having the file system block size be the same as the
virtual memory page size allows
0237.html
I don't see the dash behavior mentioned in my Debian Jessie rsyslogd
manual page though.
--
Bruce Momjian 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 +
e PG 10 release notes, which I wrote, should
have mentioned this. :-(
https://www.postgresql.org/docs/10/static/release-10.html
--
Bruce Momjian 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 +
40 matches
Mail list logo
