Re: FW: huge SubtransSLRU and SubtransBuffer wait_event

On 2024-Mar-01, James Pang wrote: > one question: > we need to increase all SLRU buffers together , MULTIXACT, XACT, > Subtrans, COMMIT TS , for example, got all of them doubled based on > existing size ? No need. > or only increase Subtrans , or Subtrans and multixact ? Just increase

Re: FW: huge SubtransSLRU and SubtransBuffer wait_event

> Possible to increase Subtrans SLRU buffer size ? Not at present -- you need to recompile after changing NUM_SUBTRANS_BUFFERS in src/include/access/subtrans.h, NUM_MULTIXACTOFFSET_BUFFERS and NUM_MULTIXACTMEMBER_BUFFERS in src/include/access/multixact.h. one question: we need to

Re: Optimizing count(), but Explain estimates wildly off

> > > Reading around, seems many people are still using this 2005 snippet to > obtain the > > row count estimate from Explain: > > I recommend using FORMAT JSON and extracting the top row count from that. > It is > simpler and less error-prone. > Good tip, thanks Laurenze! > > > Is this still the

Table Partitioning and Indexes Performance Questions

I was told that partitioned table indexed must always start with the partition key columns. Is this always the case or does it depend on use case? When would you want to create indexes in this way? The documentation just mentions that it is strictly unnecessary but can be helpful. My

Re: generic plan generate poor performance

Hi čt 29. 2. 2024 v 15:28 odesílatel James Pang napsal: > Hi, >we create statistics (dependencies,distinct) on (cccid,sssid); with > real bind variables , it make good plan of Hash join , but when it try to > generic plan, it automatically convert to Nestloop and then very poor sql >

generic plan generate poor performance

Hi, we create statistics (dependencies,distinct) on (cccid,sssid); with real bind variables , it make good plan of Hash join , but when it try to generic plan, it automatically convert to Nestloop and then very poor sql performance. why generic plan change to to a poor plan "nestloop" ? how

Re: Table Partitioning and Indexes Performance Questions

On Thu, 2024-02-29 at 11:42 -0500, David Kelly wrote: > I was told that partitioned table indexed must always start with the > partition key columns. That's not true. Only unique indexes (as used by primary key and unique constraints) must contain the partitioning key (but they don't have to

Re: Table Partitioning and Indexes Performance Questions

Would eliminating triggers and stored procedure would be step #1 to start seeing gains from partitions? We have many triigers and stored procedure and i am trying to to kake sure if need to deprecate before moving to partitioning. Many thx Andy Get Outlook for Android