Hi,
On 2020-04-29 10:50:54 +0200, Laurenz Albe wrote:
On Wed, 2020-04-29 at 08:54 +0200, Marc Rechté wrote:
I am trying to figure out the recommended settings for a PG dedicated
machine regarding NUMA.
I assume that the shared buffers are using Huge Phages only. Please
correct if I am wrong:
Thanks all for suggestions.
On Mon, May 4, 2020 at 4:46 PM Craig Jackson
wrote:
> We are currently engaged in an Oracle to Postgres migration. Our DBA team
> has been going through this book and we have learned a lot from it.
>
> PostgreSQL 12 High Availability Cookbook - Third Edition
>
> https
We are currently engaged in an Oracle to Postgres migration. Our DBA team
has been going through this book and we have learned a lot from it.
PostgreSQL 12 High Availability Cookbook - Third Edition
https://www.packtpub.com/data/postgresql-12-high-availability-cookbook-third-edition
On Mon, May 4
I don't know the others, but have enjoyed and learned a great deal from The
Art of PostgreSQL.
>
Hi,
I am Oracle DBA for 20+ years and well verse with Oracle internal and all
related details, performance optimization , replication etc...
So I 'm looking for acquiring similar expertise for Postgresql.
Now I am using Aurora Postgresql and looking for excellent technical book
for Posgresql inte
The change is abrupt, on the 10th execution (but I hadn't spotted it was
always after the same number of executions until your suggestion - thanks
for pointing me in that direction).
I don't see any custom configuration on our end that changes the threshold
for this from 5->10. Debugging the query
On Mon, 4 May 2020 at 02:35, James Thompson wrote:
> buffers do look different - but still, reading 42k doesn't seem like it would
> cause a delay of 4m?
You could do: SET track_io_timing TO on;
then: EXPLAIN (ANALYZE, BUFFERS) your query and see if the time is
spent doing IO.
David
On Mon, May 04, 2020 at 08:07:07PM +0100, Jamie Thompson wrote:
> Additionally, the execution plans for the 10th + following queries look
> fine, they have the same structure as if I run the query manually. It's not
> that the query plan switches, it seems as though the same query plan is
> just >
Why not vacuum analyze both tables to ensure stats are up to date?
Have you customized default_statistics_target from 100? It may be that 250
would give you a more complete sample of the table without increasing the
size of the stats tables too much such that planning time increases hugely.
Do yo
https://www.postgresql.org/docs/12/jit-decision.html
Thanks a lot David, I missed that part of the doc.
JC
Hi,
On 2020-04-29 10:50:54 +0200, Laurenz Albe wrote:
> On Wed, 2020-04-29 at 08:54 +0200, Marc Rechté wrote:
> > I am trying to figure out the recommended settings for a PG dedicated
> > machine regarding NUMA.
> >
> > I assume that the shared buffers are using Huge Phages only. Please
> > cor
On Mon, May 4, 2020 at 9:12 AM Jean-Christophe Boggio <
postgre...@thefreecat.org> wrote:
> Is there a way to disable JIT (I use the apt.postgresql.org repository)
> in both 11.6 and 12.2 ? I would have liked to disable it on this
> particular query but maybe I could live with disabling JIT everyw
Hello,
I have rewritten the function/query to make it a PLPGSQL function and
split the query in ~20 smaller queries.
Now the problem of the JIT compiler kicking in also happens on PG 11.6
Although the 2 seconds induced delay is not a serious problem when I
execute the query for thousands of i
On Sun, May 03, 2020 at 11:51:44PM -0400, Arya F wrote:
> On Sun, May 3, 2020 at 11:46 PM Michael Lewis wrote:
> > What kinds of storage (ssd or old 5400 rpm)? What else is this machine
> > running?
>
> Not an SSD, but an old 1TB 7200 RPM HDD
>
> > What configs have been customized such as work
14 matches
Mail list logo
