update non-indexed value is slow if some non-related index/fk are enabled

2021-09-05 Thread Philippe Doussot
Hi all, I'm look for some hint about this behaviour : One UPDATE of one boolean value which is non-indexed take some time ( for many tuples .. 3 Millions ). But if we disable all indexes/fk the UPDATE is 10x faster and do 10x less shared hit . I don't understand why disabling all index from

How to observe plan_cache_mode transition from custom to generic plan?

2021-09-05 Thread Richard Michael
TL;DR -- 1/ My basic prepared statement doesn't seem to start out with a custom plan (i.e., no parameter symbols in query text). 2/ EXPLAIN EXECUTE of prepared statement doesn't show query text, as the documentation seems to imply. Should it? 3/ How can I observe the effect of plan_cache_mode?

Re: update non-indexed value is slow if some non-related index/fk are enabled

2021-09-05 Thread David G. Johnston
On Friday, September 3, 2021, Philippe Doussot wrote: > > One UPDATE of one boolean value which is non-indexed take some time ( for > many tuples .. 3 Millions ). > > But if we disable all indexes/fk the UPDATE is 10x faster and do 10x less > shared hit . > > I don't understand why disabling all i

Re: update non-indexed value is slow if some non-related index/fk are enabled

2021-09-05 Thread Tom Lane
"David G. Johnston" writes: > On Friday, September 3, 2021, Philippe Doussot > wrote: >> I don't understand why disabling all index from the table speed up the >> update because the boolean column is not indexed > Index entries point to physical records. You just deleted one physical > record a

Re: How to observe plan_cache_mode transition from custom to generic plan?

2021-09-05 Thread Mladen Gogala
On 9/5/21 9:35 AM, Richard Michael wrote: TL;DR -- 1/ My basic prepared statement doesn't seem to start out with a custom plan (i.e., no parameter symbols in query text). 2/ EXPLAIN EXECUTE of prepared statement doesn't show query text, as the documentation seems to imply.  Should it? 3/ H

Re: How to observe plan_cache_mode transition from custom to generic plan?

2021-09-05 Thread David G. Johnston
On Sunday, September 5, 2021, Richard Michael wrote: > > Based on the documentation, I expected the first planned query text to > be: `SELECT 10 AS data`, since it should be a custom plan with > substituted values. However, the query text always contains a parameter > symbol: `SELECT $1 AS data`

RE: vacuum full

2021-09-05 Thread Ian Dauncey
Morning. Thanks for all the replies. What I did to remove these files was to backup of the DB, drop the DB and then I restored the DB. Regards Ian From: Vijaykumar Jain Sent: Monday, 30 August 2021 20:06 To: pgsql-general Subject: Re: vacuum full External email - treat with caution On Mon,

Re: How to observe plan_cache_mode transition from custom to generic plan?

2021-09-05 Thread Laurenz Albe
On Sun, 2021-09-05 at 14:20 -0400, Mladen Gogala wrote: > On 9/5/21 9:35 AM, Richard Michael wrote: > > TL;DR -- > > > > 1/ My basic prepared statement doesn't seem to start out with a custom > > plan > > (i.e., no parameter symbols in query text). That is notmal for the first five executions.