Thread: BUG #18600: Getting wait_type_event as IPC:BTreePage for count queries

The following bug has been logged on the website:

Bug reference:      18600
Logged by:          Aditya Singh
Email address:      aditya.singh@lji.io
PostgreSQL version: 13.11
Operating system:   macOS
Description:

Table1: 
Structure: 
CREATE TABLE "femsa"."activities_bit" (
    "id" int4 NOT NULL DEFAULT
nextval('femsa.activities_bit_copy_id_seq'::regclass),
    "created_ts" timestamptz,
    "member_id" varchar(40),
    "bit_reference" varchar(32),
    "header" jsonb,
    "payment_details" jsonb,
    PRIMARY_KEY("id")
}

Table 2:
Structure:
CREATE TABLE "femsa"."activities_bit" (
    "id" int8 NOT NULL DEFAULT
nextval('femsa.activities_bit_copy_id_seq'::regclass),
    "created_ts" timestamptz,
    "member_id" varchar(40),
    "bit_reference" varchar(32),
    "header" jsonb,
    "payment_details" jsonb,
    PRIMARY_KEY("id")
}

The only difference between the two is the data type of the id sequence
(int, bigint).

SELECT COUNT(*) FROM {table_name} WHERE id >  0;
When I try to run the above query, I get the result for Table 1, but the
query on Table 2 goes into wait_type_event IPC:BtreePage. 

Why this IPC:BtreePage is coming for Table2 when both tables have similar
structure, data and Indexes?

On 9/4/24 11:21, PG Bug reporting form wrote:
> The following bug has been logged on the website:
> 
> Bug reference:      18600
> Logged by:          Aditya Singh
> Email address:      aditya.singh@lji.io
> PostgreSQL version: 13.11
> Operating system:   macOS
> Description:        
> 
> Table1: 
> Structure: 
> CREATE TABLE "femsa"."activities_bit" (
>     "id" int4 NOT NULL DEFAULT
> nextval('femsa.activities_bit_copy_id_seq'::regclass),
>     "created_ts" timestamptz,
>     "member_id" varchar(40),
>     "bit_reference" varchar(32),
>     "header" jsonb,
>     "payment_details" jsonb,
>     PRIMARY_KEY("id")
> }
> 
> Table 2:
> Structure:
> CREATE TABLE "femsa"."activities_bit" (
>     "id" int8 NOT NULL DEFAULT
> nextval('femsa.activities_bit_copy_id_seq'::regclass),
>     "created_ts" timestamptz,
>     "member_id" varchar(40),
>     "bit_reference" varchar(32),
>     "header" jsonb,
>     "payment_details" jsonb,
>     PRIMARY_KEY("id")
> }
> 
> The only difference between the two is the data type of the id sequence
> (int, bigint).
> 
> SELECT COUNT(*) FROM {table_name} WHERE id >  0;
> When I try to run the above query, I get the result for Table 1, but the
> query on Table 2 goes into wait_type_event IPC:BtreePage. 
> 
> Why this IPC:BtreePage is coming for Table2 when both tables have similar
> structure, data and Indexes?
> 

Not sure I understood the question correctly, but chances are both
queries hit that wait event, but it's intermittent and you only noticed
that for one of them. Or are you saying it gets "stuck" in that wait
even for the table with int8 column?

Another option is that the first query does not use the index at all, in
which case it of course won't see btree wait events. We don't even know
how large the tables are, not to mention which access methods they use.

You'd have to show us explain. I'd bet the first query uses seqscan,
while the second one uses index-only scan.


regards

-- 
Tomas Vondra

On 9/5/24 10:11, Aditya Singh wrote:
> The query on the first table didn't hit the wait event; it hit on the
> second table. I can show you the same on RDS Database Insights. Both
> tables have the same *Indexes*, *Data*, and *Columns*. There is only a
> difference in the ID datatype. Is there any possibility of scheduling a
> call to troubleshoot this issue since it is happening in the Production
> environment? 
> 

As this is a RDS database, you should probably talk to AWS support?

Other than that, share the explain plans for the two queries (as I asked
in my previous response).

BTW please don't top post. It's customary to reply inline on this list.


regards

-- 
Tomas Vondra