PostgreSQL pg_repack 重新組織表并釋放表空間

pg_repack

pg_repack是 PostgreSQL 的一個擴展，它允許您從表和索引中刪除膨脹，并可選擇恢復聚集索引的物理順序。與CLUSTER和VACUUM FULL不同，它可以在線工作，在處理過程中無需對已處理的表保持獨占鎖定。pg_repack 啟動效率高，性能可與直接使用 CLUSTER 相媲美。

要求

PostgreSQL 版本
PostgreSQL 9.5、9.6、10、11、12、13、14、15、16、17。

PostgreSQL 9.4 及之前版本不受支持。

磁盤
執行全表重新打包需要的可用磁盤空間大約是目標表及其索引的兩倍。
例如，如果要重組的表和索引的總大小為 1GB，則需要額外的 2GB 磁盤空間。

安裝

pg_repack 可以在 UNIX 或 Linux 上使用make構建。在構建之前，您可能需要安裝 PostgreSQL 開發包（postgresql-devel等）并將包含pg_config的目錄添加到您的$PATH。然后您可以運行：

dnf install -y lz4-develdnf install -y readline-develdnf install -y clang sudo dnf install -y llvm llvm-develwget -c 'https://github.com/reorg/pg_repack/archive/refs/tags/ver_1.5.2.zip'cd /opt unzip  pg_repack-ver_1.5.2.zip make PG_CONFIG={your pg_config path}make PG_CONFIG={your pg_config path}  install #　安裝后，在你要處理的數據庫中加載 pg_repack 擴展。pg_repack 被打包為一個擴展，因此你可以執行：$ psql -c "CREATE EXTENSION pg_repack" -d your_databasetest=# select repack.version(), repack.version_sql();version     |   version_sql   
-----------------+-----------------pg_repack 1.5.2 | pg_repack 1.5.2
(1 row)

pgstattuple

pgstattuple 提供了一個非常詳細的表和索引空間使用統計信息，尤其是在處理表膨脹和空間碎片時非常有用。通過這些信息，您可以有效地評估表的膨脹率，并決定是否需要執行 VACUUM FULL 或 pg_repack 等操作來回收空間并優化數據庫性能。

test=# CREATE EXTENSION IF NOT EXISTS pgstattuple;
CREATE EXTENSIONtest=# select * from pg_extension ;oid  |     extname      | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition 
-------+------------------+----------+--------------+----------------+------------+-----------+--------------14528 | plpgsql          |       10 |           11 | f              | 1.0        |           | 16397 | pg_repack        |       10 |         2200 | f              | 1.5.2      |           | 16851 | pgstattuple      |       10 |         2200 | t              | 1.5        |           | 
(3 rows)

測試


### 關閉 autovacuum -- 僅測試 test=# alter system set autovacuum=off; 
ALTER SYSTEMtest=# select pg_reload_conf();pg_reload_conf 
----------------t
(1 row)test=# show autovacuum;autovacuum 
------------off
(1 row)#### 創建數據庫表CREATE TABLE big_table (id SERIAL PRIMARY KEY,name varchar(100),value INT
);CREATE INDEX idx_name on big_table(name);#### 插入測試數據#  插入 300 萬行數據
# -- 生成 Name 1, Name 2, Name 3... 的格式
# -- 生成一個在 1 到 100 之間的值INSERT INTO big_table (name, value)
SELECT'Name ' || gs,         (gs % 100) + 1        
FROM generate_series(1, 3000000) gs;# 查看表的大小和死行數量test=# SELECT * FROM pg_stat_user_tables WHERE relname = 'big_table'\gx
-[ RECORD 1 ]-------+----------
relid               | 16929
schemaname          | public
relname             | big_table
seq_scan            | 2
seq_tup_read        | 0
idx_scan            | 0
idx_tup_fetch       | 0
n_tup_ins           | 3000000
n_tup_upd           | 0
n_tup_del           | 0
n_tup_hot_upd       | 0
n_live_tup          | 3000000
n_dead_tup          | 0
n_mod_since_analyze | 3000000
n_ins_since_vacuum  | 3000000
last_vacuum         | 
last_autovacuum     | 
last_analyze        | 
last_autoanalyze    | 
vacuum_count        | 0
autovacuum_count    | 0
analyze_count       | 0
autoanalyze_count   | 0# 查看表的空間大小、索引大小，總大小
test=# SELECT
test-#      pg_size_pretty(pg_table_size('big_table')) AS table_size,
test-#      pg_size_pretty(pg_indexes_size('big_table')) AS indexes_size,
test-#      pg_size_pretty(pg_total_relation_size('big_table')) AS total_size;table_size | indexes_size | total_size 
------------+--------------+------------149 MB     | 219 MB       | 369 MB# 查詢默認表空間路徑（pg_default）中的物理文件test=# SELECT oid, datname FROM pg_database WHERE datname = 'test';oid  | datname 
-------+---------16389 | test
(1 row)test=# SELECT pg_relation_filepath('big_table');pg_relation_filepath 
----------------------base/16389/16929
(1 row)# 物理文件空間大小ls -lth |grep 16929
-rw-------. 1 postgres postgres 150M Feb 14 16:23 16929
-rw-------. 1 postgres postgres 56K Feb 14 16:22 16929_fsm# 這個查詢會返回有關指定表的空間使用統計信息。test=# SELECT * FROM pgstattuple('big_table');table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent 
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------156540928 |     3000000 | 139999608 |         89.43 |                0 |              0 |                  0 |       6668 |            0
(1 row)#### 執行一些刪除和更新操作#為了模擬數據庫的實際負載，刪除和更新一些行，產生死行和空洞：# 刪除一些數據 33%
test=# DELETE FROM big_table WHERE id%3 = 0; 
DELETE 1000000test=# select count(*) from big_table;count  
---------2000000
(1 row)test=# SELECT * FROM pg_stat_user_tables WHERE relname = 'big_table'\gx
-[ RECORD 1 ]-------+----------
relid               | 16929
schemaname          | public
relname             | big_table
seq_scan            | 8
seq_tup_read        | 11000000
idx_scan            | 0
idx_tup_fetch       | 0
n_tup_ins           | 3000000
n_tup_upd           | 0
n_tup_del           | 1000000   # 被刪除的行數 
n_tup_hot_upd       | 0
n_live_tup          | 2000000
n_dead_tup          | 1000000   # 產生死行的數量
n_mod_since_analyze | 4000000
n_ins_since_vacuum  | 3000000
last_vacuum         | 
last_autovacuum     | 
last_analyze        | 
last_autoanalyze    | 
vacuum_count        | 0
autovacuum_count    | 0
analyze_count       | 0
autoanalyze_count   | 0test=# SELECT * FROM pgstattuple('big_table');table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent 
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------156540928 |     2000000 |  93333072 |         59.62 |               10 |            480 |                  0 |   48005924 |        30.67
(1 row)# 查詢 物理文件是否發生變化ls -lth |grep 16929
-rw-------. 1 postgres postgres 150M Feb 14 16:37 16929
-rw-------. 1 postgres postgres   56K Feb 14 16:22 16929_fsm# 更新一些數據test=# UPDATE big_table SET name = name || 'updated' WHERE id%3 = 1; 
UPDATE 1000000test=# select count(*) from big_table;count  
---------2000000
(1 row)test=# SELECT * FROM pg_stat_user_tables WHERE relname = 'big_table'\gx
-[ RECORD 1 ]-------+----------
relid               | 16929
schemaname          | public
relname             | big_table
seq_scan            | 15
seq_tup_read        | 21000020
idx_scan            | 0
idx_tup_fetch       | 0
n_tup_ins           | 3000000
n_tup_upd           | 1000000  # 已更新的行
n_tup_del           | 1000000
n_tup_hot_upd       | 0
n_live_tup          | 2000000
n_dead_tup          | 2000000  # 產生死行的數量 1000000+1000000=2000000 ( n_tup_del + n_tup_upd) 
n_mod_since_analyze | 5000000
n_ins_since_vacuum  | 3000000
last_vacuum         | 
last_autovacuum     | 
last_analyze        | 
last_autoanalyze    | 
vacuum_count        | 0
autovacuum_count    | 0
analyze_count       | 0
autoanalyze_count   | 0# 檢查數據、索引文件大小 test=# SELECT * FROM pgstattuple('big_table');table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent 
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------169197568 |     2000000 |  98665204 |         58.31 |                0 |              0 |                  0 |   48622184 |        28.74
(1 row)# 查詢 物理文件是否發生變化ls -lth |grep 16929
-rw-------. 1 postgres postgres 162M Feb 14 16:44 16929
-rw-------. 1 postgres postgres  64K Feb 14 16:39 16929_fsm#運行 pg_repack 來重建表。這將移除死行并優化表：pg_repack -d test --table public.big_table --echo-------------------  日志如下  ------------------
LOG: (query) SET search_path TO pg_catalog, pg_temp, public
LOG: (query) SET search_path TO pg_catalog, pg_temp, public
LOG: (query) select repack.version(), repack.version_sql()
LOG: (query) SET statement_timeout = 0
LOG: (query) SET search_path = pg_catalog, pg_temp, public
LOG: (query) SET client_min_messages = warning
LOG: (query) SELECT r FROM (VALUES ($1, 'r')) AS given_t(r,kind) WHERE NOT EXISTS(  SELECT FROM repack.tables WHERE relid=to_regclass(given_t.r)) AND NOT EXISTS(  SELECT FROM pg_catalog.pg_class c WHERE c.oid=to_regclass(given_t.r) AND c.relkind = given_t.kind AND given_t.kind = 'p')
LOG:    (param:0) = public.big_table
LOG: (query) SELECT t.*, coalesce(v.tablespace, t.tablespace_orig) as tablespace_dest FROM repack.tables t,  (VALUES ($1::text)) as v (tablespace) WHERE (relid = $2::regclass) ORDER BY t.relname, t.schemaname
LOG:    (param:0) = (null)
LOG:    (param:1) = public.big_table
INFO: repacking table "public.big_table"
LOG: (query) SELECT pg_try_advisory_lock($1, CAST(-2147483648 + $2::bigint AS integer))
LOG:    (param:0) = 16185446
LOG:    (param:1) = 16929
LOG: (query) BEGIN ISOLATION LEVEL READ COMMITTED
LOG: (query) SET LOCAL lock_timeout = 100
LOG: (query) LOCK TABLE public.big_table IN ACCESS EXCLUSIVE MODE
LOG: (query) RESET lock_timeout
LOG: (query) SELECT pg_get_indexdef(indexrelid) FROM pg_index WHERE indrelid = $1 AND NOT indisvalid
LOG:    (param:0) = 16929
LOG: (query) SELECT indexrelid, repack.repack_indexdef(indexrelid, indrelid, $2, FALSE)  FROM pg_index WHERE indrelid = $1 AND indisvalid
LOG:    (param:0) = 16929
LOG:    (param:1) = (null)
LOG: (query) SELECT repack.conflicted_triggers($1)
LOG:    (param:0) = 16929
LOG: (query) SELECT repack.create_index_type(16933,16929)
LOG: (query) SELECT repack.create_log_table(16929)
LOG: (query) CREATE TRIGGER repack_trigger AFTER INSERT OR DELETE OR UPDATE ON public.big_table FOR EACH ROW EXECUTE PROCEDURE repack.repack_trigger('id')
LOG: (query) ALTER TABLE public.big_table ENABLE ALWAYS TRIGGER repack_trigger
LOG: (query) SELECT repack.disable_autovacuum('repack.log_16929')
LOG: (query) BEGIN ISOLATION LEVEL READ COMMITTED
LOG: (query) SELECT pg_backend_pid()
LOG: (query) SELECT pid FROM pg_locks WHERE locktype = 'relation' AND granted = false AND relation = 16929 AND mode = 'AccessExclusiveLock' AND pid <> pg_backend_pid()
LOG: (query) COMMIT
LOG: (query) BEGIN ISOLATION LEVEL SERIALIZABLE
LOG: (query) SELECT set_config('work_mem', current_setting('maintenance_work_mem'), true)
LOG: (query) SELECT coalesce(array_agg(l.virtualtransaction), '{}')   FROM pg_locks AS l   LEFT JOIN pg_stat_activity AS a     ON l.pid = a.pid   LEFT JOIN pg_database AS d     ON a.datid = d.oid   WHERE l.locktype = 'virtualxid'   AND l.pid NOT IN (pg_backend_pid(), $1)   AND (l.virtualxid, l.virtualtransaction) <> ('1/1', '-1/0')   AND (a.application_name IS NULL OR a.application_name <> $2)  AND a.query !~* E'^\\s*vacuum\\s+'   AND a.query !~ E'^autovacuum: '   AND ((d.datname IS NULL OR d.datname = current_database()) OR l.database = 0)
LOG:    (param:0) = 12616
LOG:    (param:1) = pg_repack
LOG: (query) DELETE FROM repack.log_16929
LOG: (query) SAVEPOINT repack_sp1
LOG: (query) SELECT pid FROM pg_locks WHERE locktype = 'relation' AND granted = false AND relation = 16929 AND mode = 'AccessExclusiveLock' AND pid <> pg_backend_pid()
LOG: (query) SET LOCAL lock_timeout = 100
LOG: (query) LOCK TABLE public.big_table IN ACCESS SHARE MODE
LOG: (query) RESET lock_timeout
LOG: (query) SELECT repack.create_table($1, $2)
LOG:    (param:0) = 16929
LOG:    (param:1) = pg_default
LOG: (query) INSERT INTO repack.table_16929 SELECT id,name,value FROM ONLY public.big_table
LOG: (query) SELECT repack.disable_autovacuum('repack.table_16929')
LOG: (query) COMMIT
LOG: (query) SELECT 'repack.table_16929'::regclass::oid
LOG: (query) CREATE UNIQUE INDEX index_16933 ON repack.table_16929 USING btree (id)
LOG: (query) CREATE INDEX index_16935 ON repack.table_16929 USING btree (name)
LOG: (query) SELECT repack.repack_apply($1, $2, $3, $4, $5, $6)
LOG:    (param:0) = SELECT * FROM repack.log_16929 ORDER BY id LIMIT $1
LOG:    (param:1) = INSERT INTO repack.table_16929 VALUES ($1.*)
LOG:    (param:2) = DELETE FROM repack.table_16929 WHERE (id) = ($1.id)
LOG:    (param:3) = UPDATE repack.table_16929 SET (id, name, value) = ($2.id, $2.name, $2.value) WHERE (id) = ($1.id)
LOG:    (param:4) = DELETE FROM repack.log_16929 WHERE id IN (
LOG:    (param:5) = 1000
LOG: (query) SELECT pid FROM pg_locks WHERE locktype = 'virtualxid' AND pid <> pg_backend_pid() AND virtualtransaction = ANY($1)
LOG:    (param:0) = {}
LOG: (query) SAVEPOINT repack_sp1
LOG: (query) SET LOCAL lock_timeout = 100
LOG: (query) LOCK TABLE public.big_table IN ACCESS EXCLUSIVE MODE
LOG: (query) RESET lock_timeout
LOG: (query) SAVEPOINT repack_sp1
LOG: (query) SET LOCAL lock_timeout = 100
LOG: (query) LOCK TABLE repack.table_16929 IN ACCESS EXCLUSIVE MODE
LOG: (query) RESET lock_timeout
LOG: (query) SELECT repack.repack_apply($1, $2, $3, $4, $5, $6)
LOG:    (param:0) = SELECT * FROM repack.log_16929 ORDER BY id LIMIT $1
LOG:    (param:1) = INSERT INTO repack.table_16929 VALUES ($1.*)
LOG:    (param:2) = DELETE FROM repack.table_16929 WHERE (id) = ($1.id)
LOG:    (param:3) = UPDATE repack.table_16929 SET (id, name, value) = ($2.id, $2.name, $2.value) WHERE (id) = ($1.id)
LOG:    (param:4) = DELETE FROM repack.log_16929 WHERE id IN (
LOG:    (param:5) = 0
LOG: (query) SELECT repack.repack_swap($1)
LOG:    (param:0) = 16929
LOG: (query) COMMIT
LOG: (query) BEGIN ISOLATION LEVEL READ COMMITTED
LOG: (query) SAVEPOINT repack_sp1
LOG: (query) SET LOCAL lock_timeout = 100
LOG: (query) LOCK TABLE public.big_table IN ACCESS EXCLUSIVE MODE
LOG: (query) RESET lock_timeout
LOG: (query) SELECT repack.repack_drop($1, $2)
LOG:    (param:0) = 16929
LOG:    (param:1) = 4
LOG: (query) COMMIT
LOG: (query) BEGIN ISOLATION LEVEL READ COMMITTED
LOG: (query) ANALYZE public.big_table
LOG: (query) COMMIT
LOG: (query) SELECT pg_advisory_unlock($1, CAST(-2147483648 + $2::bigint AS integer))
LOG:    (param:0) = 16185446
LOG:    (param:1) = 16929# 創建觸發器跟蹤新表--舊表test=# \d big_tableTable "public.big_table"Column |          Type          | Collation | Nullable |                Default                
--------+------------------------+-----------+----------+---------------------------------------id     | integer                |           | not null | nextval('big_table_id_seq'::regclass)name   | character varying(100) |           |          | value  | integer                |           |          | 
Indexes:"big_table_pkey" PRIMARY KEY, btree (id)"idx_name" btree (name)
Triggers firing always:repack_trigger AFTER INSERT OR DELETE OR UPDATE ON big_table FOR EACH ROW EXECUTE FUNCTION repack.repack_trigger('id')# 創建新表
test=# set search_path=public,repack;
SETtest=# \dList of relationsSchema |       Name        |   Type   |    Owner     
--------+-------------------+----------+--------------public | big_table         | table    | postgrespublic | big_table_id_seq  | sequence | postgrespublic | student           | table    | postgrespublic | test_table        | table    | postgrespublic | test_table_id_seq | sequence | postgresrepack | log_16929         | table    | postgres   # 創建日志表：  log_[relid], 新數據記錄到這張表 repack | log_16929_id_seq  | sequence | postgresrepack | primary_keys      | view     | postgresrepack | table_16929       | table    | postgres   # 創建臨時表：  表名_[relid]repack | tables            | view     | postgres
(10 rows)# 產生新的數據test=# select * from log_16929;id |    pk     |               row                
----+-----------+----------------------------------1 |           | (3000004,"name inserted",99)2 | (367871)  | (367871,"Name 367871updated",72)3 | (3000004) | 4 |           | (3000005,"name inserted",99)5 | (3000005) | 
(5 rows)test=# SELECT pg_relation_filepath('big_table');pg_relation_filepath 
----------------------base/16389/16949
(1 row)# 查詢 物理文件是否發生變化ls -lth |grep 16949
-rw-------. 1 postgres postgres 108M Feb 14 16:52 16949
-rw-------. 1 postgres postgres  48K Feb 14 16:52 16949_fsm# 檢查膨脹率  test=# SELECT * FROM pgstattuple('big_table');table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent 
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------112607232 |     2000000 |  98665260 |         87.62 |                8 |            384 |                  0 |     229804 |          0.2
(1 row)

重建表總結：

原理介紹

pg_repack插件支持對全表和索引進行repack操作。
對全表進行repack的實現原理如下：

1.創建日志表，記錄repack期間對原表的變更。
2.在原表上創建觸發器，將原表的INSERT、UPDATE和DELETE操作記錄到日志表中。
3.創建原表結構相同的新表并將原表數據導入其中。
4.在新表中創建與原表相同的索引。
5.將日志表里的變更（即repack期間表上產生的增量數據）應用到新表。
6.在系統catalog交換新舊表。
7.刪除舊表。

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/diannao/76426.shtml
繁體地址，請注明出處：http://hk.pswp.cn/diannao/76426.shtml
英文地址，請注明出處：http://en.pswp.cn/diannao/76426.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

5G_WiFi_CE_射頻輸出功率、發射功率控制（TPC）和功率密度測試

5G_WiFi_CE_射頻輸出功率、發射功率控制（TPC）和功率密度測試

目錄 一、規范要求 1、法規目錄&#xff1a; &#xff08;1&#xff09;RF Output Power (2)Transmit Power Control (TPC) &#xff08;3&#xff09;Power Density 2、限值&#xff1a; 二、EIRP測試方法 &#xff08;1&#xff09;測試條件 &#xff08;2&#xff…
閱讀更多...
掃描線離散化線段樹解決矩形面積并-洛谷P5490

掃描線離散化線段樹解決矩形面積并-洛谷P5490

https://www.luogu.com.cn/problem/P5490 題目描述 求 n n n 個四邊平行于坐標軸的矩形的面積并。 輸入格式 第一行一個正整數 n n n。 接下來 n n n 行每行四個非負整數 x 1 , y 1 , x 2 , y 2 x_1, y_1, x_2, y_2 x1?,y1?,x2?,y2?&#xff0c;表示一個矩形的四個…
閱讀更多...
Java項目之基于ssm的簡易版營業廳寬帶系統（源碼+文檔）

Java項目之基于ssm的簡易版營業廳寬帶系統（源碼+文檔）

項目簡介 簡易版營業廳寬帶系統實現了以下功能&#xff1a; 此營業廳寬帶系統利用當下成熟完善的SSM框架&#xff0c;使用跨平臺的可開發大型商業網站的Java語言&#xff0c;以及最受歡迎的RDBMS應用軟件之一的Mysql數據庫進行程序開發。實現了營業廳寬帶系統基礎數據的管理&…
閱讀更多...
從入門到入土，SQLServer 2022慢查詢問題總結

從入門到入土，SQLServer 2022慢查詢問題總結

列為，由于公司原因，作者接觸了一個SQLServer 2022作為數據存儲到項目，可能是上一任的哥們兒離開的時候帶有情緒，所以現在項目的主要問題就是，所有功能都實現了，但是就是慢，列表頁3s打底，客戶很生氣，經過幾周摸爬滾打，作以下總結，作為自己的成長記錄。 一、索引問題…
閱讀更多...
PDF處理控件Aspose.PDF教程：在Python、Java 和 C# 中旋轉 PDF 文檔

PDF處理控件Aspose.PDF教程：在Python、Java 和 C# 中旋轉 PDF 文檔

您是否希望快速輕松地在線旋轉PDF文檔&#xff1f;無論您需要修復文檔的方向還是只想重新排列頁面&#xff0c;本指南都能滿足您的需求。有簡單的方法可以解決此問題 - 無論您喜歡在線工具還是編程解決方案。 在本指南中&#xff0c;我們將向您展示如何免費在線旋轉 PDF&#…
閱讀更多...
編譯原理:first集和follow

編譯原理:first集和follow

一、First 集&#xff08;首符號集&#xff09; 定義&#xff1a; 對于符號&#xff08;非終結符或終結符&#xff09;或符號串&#xff0c;First 集是該符號串能夠推導出的所有可能開頭的終結符的集合。若符號串可以推導出空串&#xff08;ε&#xff09;&#xff0c;則 ε 也…
閱讀更多...
python實現簡單fast-cgi服務，對接到nginx

python實現簡單fast-cgi服務，對接到nginx

python代碼 import socket import struct import threading# FastCGI 頭格式&#xff08;8 字節&#xff09; FCGI_HEADER_FORMAT "!BBHHBx" FCGI_VERSION 1 FCGI_TYPE_BEGIN_REQUEST 1 FCGI_TYPE_PARAMS 4 FCGI_TYPE_STDIN 5 FCGI_TYPE_STDOUT 6 FCGI_TYPE_E…
閱讀更多...
vue開始時間小于等于結束時間，且開始時間小于等于系統時間，時間格式：年月日時分

vue開始時間小于等于結束時間，且開始時間小于等于系統時間，時間格式：年月日時分

// 日期配置 export const DATA_CONFIGS [{itemKey: "startDate",startDateKey: "startDate",endDateKey: "endDate",isStart: true,},{itemKey: "endDate",startDateKey: "startDate",endDateKey: "endDate",is…
閱讀更多...
PyCharm 下載與安裝教程：從零開始搭建你的 Python 開發環境

PyCharm 下載與安裝教程：從零開始搭建你的 Python 開發環境

PyCharm 是一款專為 Python 開發設計的集成開發環境&#xff08;IDE&#xff09;&#xff0c;它提供了強大的代碼編輯、調試、版本控制等功能&#xff0c;是 Python 開發者的必備工具之一。如果你是初學者&#xff0c;或者正在尋找一款高效的開發工具&#xff0c;這篇文章將幫助…
閱讀更多...
Qt線程等待條件QWaitCondition

Qt線程等待條件QWaitCondition

Qt 線程等待條件 概念 Qt提供了QWaitCondition類實現“等待條件”式的線程控制方法&#xff0c;它讓線程阻塞在等待條件的地方&#xff0c;直到條件滿足后才繼續執行下去。也就是說&#xff0c;QWaitCondition可以使一個線程在滿足一定條件時通知其他多個線程&#xff0c;使它…
閱讀更多...
RAG 和 RAGFlow 學習筆記

RAG 和 RAGFlow 學習筆記

一、RAG&#xff08;檢索增強生成&#xff09; 1. RAG 的定義與核心思想 RAG&#xff08;Retrieval-Augmented Generation&#xff0c;檢索增強生成&#xff09; 是一種結合 信息檢索&#xff08;Retrieval&#xff09; 和 文本生成&#xff08;Generation&#xff09; 的技術…
閱讀更多...
Windows連接服務器Ubuntu_MobaXterm

Windows連接服務器Ubuntu_MobaXterm

通過 SSH 遠程連接&#xff08;命令行方式&#xff09; &#x1f527; 所需工具&#xff1a; Windows&#xff1a;MobaXterm&#xff08;強烈推薦&#xff09;或 PuTTY Ubuntu&#xff1a;已開啟 SSH 服務 Ubuntu 開啟 SSH 服務&#xff08;僅需一次&#xff09; 在 Ubuntu …
閱讀更多...
Rust 中的高效視頻處理：利用硬件加速應對高分辨率視頻

Rust 中的高效視頻處理：利用硬件加速應對高分辨率視頻

引言 在視頻處理領域&#xff0c;隨著4K、8K甚至更高分辨率內容的普及&#xff0c;傳統的CPU計算方式逐漸顯得力不從心。無論是視頻剪輯、直播流處理還是格式轉換&#xff0c;高負載場景下CPU占用過高的問題常常讓開發者頭疼。硬件加速技術通過利用GPU等專用硬件分擔編解碼任務…
閱讀更多...
大模型提示工程中，提示、補全、指令、上下文和樣本這幾個概念的區別是什么？

大模型提示工程中，提示、補全、指令、上下文和樣本這幾個概念的區別是什么？

提示 (Prompt) 定義&#xff1a;輸入給大模型的完整文本刺激&#xff0c;是與模型交互的主要方式。 特點&#xff1a; 是最廣義的概念&#xff0c;包含其他幾個元素整體輸入的總和&#xff0c;包括指令、上下文和樣本等內容決定模型如何理解和處理請求 示例&#xff1a; 分…
閱讀更多...
AI的未來演進

AI的未來演進

企業數字IP實戰&#xff1a;創始人分身如何實現品宣獲客雙贏&#xff1f; ——從量子化建模到聯邦學習的全鏈路技術拆解 一、行業痛點&#xff1a;品牌信任與獲客效率的雙重困局 2025年數據顯示&#xff0c;73%的企業因傳統營銷模式效率低下錯失市場機遇&#xff08;家居品牌…
閱讀更多...
軟件定義無線電39

軟件定義無線電39

13.8 RFSoC上PYNQ的SDR設計流程 本節中詳細介紹的設計過程可以分為六個獨立的步驟&#xff0c;如圖13.16所示&#xff0c;并在接下來的幾頁中進行討論。 13.8.1 初始設計過程 。在這里&#xff0c;系統設計人員必須考慮許多因素&#xff0c;例如RFDC接收和/或發送的頻率范圍…
閱讀更多...
?自動化網絡架構搜索（Neural Architecture Search，NAS）

?自動化網絡架構搜索（Neural Architecture Search，NAS）

NAS是一種旨在自動設計神經網絡結構的技術。傳統上&#xff0c;神經網絡的架構設計依賴于專家的經驗和大量的試錯過程&#xff0c;而NAS通過算法自動搜索網絡架構&#xff0c;以發現最適合特定任務的神經網絡設計。 NAS的主要組成部分包括&#xff1a; 搜索空間&#xff1a;定…
閱讀更多...
Ubuntu 22.04 安裝和運行 EDK2 超詳細教程

Ubuntu 22.04 安裝和運行 EDK2 超詳細教程

Ubuntu 22.04 安裝和運行 EDK2 超詳細教程 適合新手小白&#xff0c;從零開始 &#x1f31f; 1. 什么是 EDK2&#xff1f; EDK2&#xff08;EFI Development Kit 2&#xff09;是一個開源的 UEFI&#xff08;統一可擴展固件接口&#xff09;開發環境&#xff0c;主要用于編寫和…
閱讀更多...
什么是STEP認證

什么是STEP認證

**什么是STEP認證** STEP認證&#xff0c;全稱為“可持續紡織生產認證”&#xff08;Sustainable Textile Production&#xff09;&#xff0c;是一項由國際環保紡織協會Oeko-Tex提供的權威獨立認證體系。這一認證體系猶如紡織和皮革行業的綠色燈塔&#xff0c;為追求可持續發…
閱讀更多...
odoo-045 ModuleNotFoundError: No module named ‘_sqlite3‘

odoo-045 ModuleNotFoundError: No module named ‘_sqlite3‘

文章目錄 一、問題二、解決思路 一、問題 就是項目啟動&#xff0c;本來好好地&#xff0c;忽然有一天報錯&#xff0c;不知道什么原因。 背景&#xff1a; 我是在虛擬環境中使用的python3.7。 二、解決思路 虛擬環境和公共環境直接安裝 sqlite3 都會報找不到這個庫的問題…
閱讀更多...
最新文章

Copyright @ 2022~2023