PostgreSQL LOGGED和UNLOGGED表性能与LOCK TABLE的使用比较

Question

I am trying to measure UPDATE speed on LOGGED and UNLOGGED tables in PostgreSQL(10.3). I want to use LOCK TABLE to prevent other applications from interfering with each other.

If UPDATE is performed without using LOCK TABLE , I get ~ 1K for the LOGGED table, ~ 4K for the UNLOGGED table.

If UPDATE is performed using LOCK TABLE , the results are the same for both table types.

Why does LOCK TABLE return the same result in both table types?

My PL/pgSQL function:

CREATE OR REPLACE FUNCTION public.myfunction(user_id integer, unitprice numeric(10,6), 
            islock boolean, useunlogged boolean) RETURNS integer AS
$BODY$
declare howMuch integer;
begin       
    if islock then
        if useunlogged then 
            LOCK TABLE credittable_unlogged IN ACCESS EXCLUSIVE MODE;
        else
            LOCK TABLE credittable IN ACCESS EXCLUSIVE MODE;
        end if;
    end if;
    if useunlogged then     
        select (credit_amount/unitprice)::integer into howMuch from credittable where userid=user_id and credit_amount>=unitprice;
        if howMuch is null then 
            select 0 into howMuch;
        else
            update credittable set credit_amount=credit_amount-unitprice where userid=user_id;
        end if;    
    else 
        select (credit_amount/unitprice)::integer into howMuch from credittable_unlogged where userid=user_id and credit_amount>=unitprice;
        if howMuch is null then 
           select 0 into howMuch;
        else
            update credittable_unlogged set credit_amount=credit_amount-unitprice where userid=user_id;
        end if;  
    end if;
    RETURN howMuch;
 end;
 $BODY$
   LANGUAGE plpgsql VOLATILE
    COST 100;
 ALTER FUNCTION public.myfunction(integer, numeric, boolean, boolean)
    OWNER TO postgres;

My Java code:

for(int i=1;i<=4;i++){
    long startTime = System.nanoTime();
    int counter = 0;        
    while ((System.nanoTime() - startTime) < 1000000000L) {
        CallableStatement callst = null;
        try {
            String sql = "{? = call public.myfunction(?,?,?,?) }";
            callst = con.prepareCall(sql);
            callst.registerOutParameter(1, Types.INTEGER);
            callst.setInt(2, 123456);
            callst.setBoolean(3, (i > 2));
            callst.setBoolean(4, (i%2 != 0));
            callst.setBigDecimal(3, BigDecimal.valueOf(0.001));
            callst.execute();
            int howMuch = callst.getInt(1);                
            counter++;                
        } catch (SQLException e) {
            e.printStackTrace();
        } finally {
            if (callst != null) {
                callst.close();
            }
        }
    }
    System.out.println("Counter :"+counter);
}   

Answer 1

A lot of what you are measuring here is client-server latency and PL/pgSQL execution.

The difference is caused by the necessity to sync WAL to disk.

If you use an unlogged table, and you don't use the LOCK statement, no WAL is written, and nothing has to be sync'ed at COMMIT time.

Explicit table locks cause a WAL record to be written, so COMMIT still has to sync WAL, and you lose the advantage you have from an unlogged table.

You can use pg_waldump to examine the WAL files, then you'll see what transaction log records are written.

But I can show it to you with my PostgreSQL v11, built with -DWAL_DEBUG .

This is my test table:

postgres=# \d t
             Unlogged table "public.t"
 Column |  Type   | Collation | Nullable | Default 
--------+---------+-----------+----------+---------
 id     | integer |           |          | 

Here an INSERT without LOCK TABLE :

postgres=# SET wal_debug=on;
SET
postgres=# BEGIN;
BEGIN
postgres=# INSERT INTO t VALUES (100);
INSERT 0 1
postgres=# COMMIT;
LOG:  INSERT @ 0/166BFB8:  - Transaction/COMMIT: 2018-05-18 20:34:20.060635+02
STATEMENT:  COMMIT;
COMMIT

There was a commit, but no WAL flush.

postgres=# BEGIN;
BEGIN
postgres=# LOCK TABLE t;
LOG:  INSERT @ 0/166C038:  - Standby/LOCK: xid 569 db 13344 rel 16384 
STATEMENT:  LOCK TABLE t;
LOCK TABLE
postgres=# INSERT INTO t VALUES (101);
INSERT 0 1
postgres=# COMMIT;
LOG:  INSERT @ 0/166C138:  - Transaction/COMMIT: 2018-05-18 20:36:15.419081+02
STATEMENT:  COMMIT;
LOG:  xlog flush request 0/166C138; write 0/166BFF0; flush 0/166BFF0
STATEMENT:  COMMIT;
COMMIT

Now we have a WAL flush, and that is the expensive part.

You see that a Standby/LOCK record was written.

One way to get around that is to reduce wal_level to minimal and max_wal_senders to 0 , then these WAL records don't have to be written. But then you cannot have WAL archiving and point-in-time recovery.

The other workaround is to use a lower lock level than ACCESS EXCLUSIVE . That should be fine unless you absolutely have to block readers.