Secara Otomatis Jatuhkan Tabel dan Indeks yang Lebih Lama dari 90 Hari

Sidenote/DISCLAIMER:
Ini adalah ide yang buruk, karena waktu pembuatan tabel ini tidak 100% dapat diandalkan, karena tabel mungkin telah dihapus secara internal dan dibuat ulang karena operasi pada tabel, seperti CLUSTER.

Selain itu, Anda bisa mendapatkan waktu pembuatan seperti ini (dengan asumsi nama-tabel-contoh t_benutzer ):

--select datname, datdba from pg_database;
--select relname, relfilenode from pg_class where relname ilike 't_benutzer';

    -- (select relfilenode::text from pg_class where relname ilike 't_benutzer')




SELECT 
    pg_ls_dir
    ,
    (
        SELECT creation
        FROM pg_stat_file('./base/'
            ||
            (
                    SELECT 
                        MAX(pg_ls_dir::bigint)::text 
                    FROM pg_ls_dir('./base') 
                    WHERE pg_ls_dir <> 'pgsql_tmp' 
                    AND  pg_ls_dir::bigint  <= (SELECT relfilenode FROM pg_class WHERE relname ILIKE 't_benutzer')
            )
            || '/' || pg_ls_dir
        )
    ) as createtime 
FROM pg_ls_dir(
    './base/' || 
    (
        SELECT 
            MAX(pg_ls_dir::bigint)::text 
        FROM pg_ls_dir('./base') 
        WHERE pg_ls_dir <> 'pgsql_tmp' 
        AND  pg_ls_dir::bigint  <= (SELECT relfilenode FROM pg_class WHERE relname ILIKE 't_benutzer') 
    ) 
) 

WHERE pg_ls_dir = (SELECT relfilenode::text FROM pg_class WHERE relname ILIKE 't_benutzer')

Rahasianya adalah menggunakan pg_stat_file pada file tabel masing-masing.

-- http://www.greenplumdba.com/greenplum-dba-faq/howtofindtablecreationdateingreenplum


select 
    pg_ls_dir
    , 
    (
        select 
            --size 
            --access
            --modification 
            --change
            creation 
            --isdir
        from pg_stat_file(pg_ls_dir)
    ) as createtime 
from pg_ls_dir('.'); 

Sesuai komentar di postingan ini PostgreSQL:Waktu pembuatan tabel ini tidak 100% dapat diandalkan, karena tabel mungkin telah dihapus secara internal dan dibuat ulang karena operasi pada tabel, seperti CLUSTER.

Juga polanya

/main/base/<database id>/<table filenode id> 

tampaknya salah, seperti pada mesin saya, semua tabel dari database yang berbeda memiliki id database yang sama, dan sepertinya folder tersebut telah diganti dengan beberapa nomor inode arbitrer, jadi Anda perlu menemukan folder yang nomornya paling dekat dengan tabel Anda inode id (nama folder maks di mana folderid <=table_inode_id dan nama folder adalah numerik)

Versi sederhananya seperti ini:

SELECT creation 
FROM pg_stat_file(
    './base/'
    ||
    (
        SELECT 
        MAX(pg_ls_dir::bigint)::text 
        FROM pg_ls_dir('./base') 
        WHERE pg_ls_dir <> 'pgsql_tmp' 
        AND  pg_ls_dir::bigint  <= (SELECT relfilenode FROM pg_class WHERE relname ILIKE 't_benutzer')
    )
    || '/' || (SELECT relfilenode::text FROM pg_class WHERE relname ILIKE 't_benutzer')
)

Kemudian Anda dapat menggunakan information_schema dan cte untuk membuat kueri menjadi sederhana, atau membuat tampilan Anda sendiri:

;WITH CTE AS
(
    SELECT 
        table_name 

        ,
        (
            SELECT 
                MAX(pg_ls_dir::bigint)::text 
            FROM pg_ls_dir('./base') 
            WHERE pg_ls_dir <> 'pgsql_tmp' 
            AND  pg_ls_dir::bigint  <= (SELECT relfilenode FROM pg_class WHERE relname ILIKE table_name)
        ) as folder 

        
        ,(SELECT relfilenode FROM pg_class WHERE relname ILIKE table_name) filenode
        
    FROM information_schema.tables
    WHERE table_type = 'BASE TABLE'
    AND table_schema = 'public'
)

SELECT 
    table_name 
    ,(
        SELECT creation 
        FROM pg_stat_file(
            './base/' || folder || '/' || filenode 
        )
    ) as creation_time
FROM CTE 

(semua tabel dibuat dengan skema nhibernate, jadi waktu yang kurang lebih sama pada semua tabel di screenshot sudah benar).

Untuk risiko dan efek samping, gunakan otak Anda dan/atau tanyakan kepada dokter atau apoteker Anda;)