我使用的软件,这使得一个很大的PostgreSQL数据库(有一个表中有一个百万行)和开发商说我应该VACUUM和ANALYZE周期性。但是 PostgreSQL 数据库默认是autovacuum开启的。
我应该抽真空/分析吗?有什么好处?自动抽真空和手动抽真空有什么区别
例如,在 Pgadmin3 中,我有这个:

我想列出 PostgreSQL 9.1 中由动态触发器创建的所有分区。
我能够使用Frank Heikens 的这个相关答案生成分区计数。
我有一个表foo有一个INSERT触发器创建foo_1,foo_2等动态。插入的分区是根据主键 id 选择的,这是一种基于范围的分区。
是否可以显示 table 的当前所有分区foo?
我有一个表,其中数据占用 200 GB 大小,其上的 6 个索引占用 180 GB 大小。它膨胀了 30%,所以我想回收它占用的不需要的空间。它聚集在job_id_idx 索引上。
那么要回收空间我需要使用cluster命令还是vacuum full命令?
这两个命令有什么区别?
是vacuum full为了通过一些列相同cluster的命令?
两个命令中是否都重新创建了索引?
在我的情况下,哪一个会更快?
PostgreSQL 数据库版本为 9.1
这是我的实际问题的一个最小示例:
create table t(id serial primary key, rnd double precision);
Run Code Online (Sandbox Code Playgroud)
当然,您可以使用returning子句返回插入的列:
with w as (insert into t(rnd) values(random()) returning *)
insert into t(rnd) select random() from w returning *;
/*
| ID | RND |
|----|----------------|
| 9 | 0.203221440315 |
*/
Run Code Online (Sandbox Code Playgroud)
你也可以返回一个文字:
with w as (insert into t(rnd) values(random()) returning *)
insert into t(rnd) select random() from w returning *, 1.0 dummy;
/*
| ID | RND | DUMMY |
|----|----------------|-------|
| 11 | 0.594980469905 | 1 …Run Code Online (Sandbox Code Playgroud) 鉴于表:
Column | Type
id | integer
latitude | numeric(9,6)
longitude | numeric(9,6)
speed | integer
equipment_id | integer
created_at | timestamp without time zone
Indexes:
"geoposition_records_pkey" PRIMARY KEY, btree (id)
Run Code Online (Sandbox Code Playgroud)
该表有 2000 万条记录,相对而言,这不是一个大数目。但它会使顺序扫描变慢。
我怎样才能获得max(created_at)每个的最后一条记录 ( ) equipment_id?
我已经尝试了以下两个查询,其中有几个变体,我已经阅读了本主题的许多答案:
select max(created_at),equipment_id from geoposition_records group by equipment_id;
select distinct on (equipment_id) equipment_id,created_at
from geoposition_records order by equipment_id, created_at desc;
Run Code Online (Sandbox Code Playgroud)
我也尝试过创建 btree 索引,equipment_id,created_at但 Postgres 发现使用 seqscan 更快。强制enable_seqscan = off也没有用,因为读取索引与 seq 扫描一样慢,可能更糟。
查询必须定期运行,始终返回最后一个。
使用 Postgres …
数据库通常是非常可定制的,具有不同的数据类型和自定义长度。
这让我感到惊讶,因为我试图寻找语法来使用unsigned int它们在 PostgreSQL 和 MS SQL Server 中都不可用的类型。MySQL 和 Oracle 似乎都可以。
这对他们来说似乎是一个明显的遗漏 - 下一个最佳性能选项是 long/bigint,(8 字节整数),但可能完全没有必要!有谁知道为什么他们会选择不包含本机 unsigned int 支持?
我不知道如何更新 PostgreSQL 9.3 数据类型中的元素。
我的例子:
CREATE TABLE "user"
(
id uuid NOT NULL,
password character varying(255),
profiles json,
gender integer NOT NULL DEFAULT 0,
created timestamp with time zone,
connected timestamp with time zone,
modified timestamp with time zone,
active integer NOT NULL DEFAULT 1,
settings json,
seo character varying(255) NOT NULL,
CONSTRAINT id_1 PRIMARY KEY (id)
)
WITH (
OIDS=TRUE
);
ALTER TABLE "user"
OWNER TO postgres;
Run Code Online (Sandbox Code Playgroud)
“配置文件”中的 json 部分
CREATE TABLE "user"
(
id uuid NOT NULL,
password …Run Code Online (Sandbox Code Playgroud) Postgres 如何触发机制规模?
我们有一个大型的 PostgreSQL 安装,我们正在尝试使用日志表和 TRIGGER(s) 来实现一个基于事件的系统。
基本上,我们希望为每个我们希望收到更新/插入/删除操作通知的表创建一个 TRIGGER。一旦触发此触发器,它将执行一个函数,该函数将简单地将一个新行(对事件进行编码)附加到一个日志表中,然后我们将从外部服务轮询该日志表。
在全面使用 Postgres TRIGGER(s) 之前,我们想知道它们是如何扩展的:我们可以在单个 Postgres 安装上创建多少个触发器?它们会影响查询性能吗?有没有人试过这个?
是的,我知道数据规范化应该是我的首要任务(因为它是)。
used_vehicle,color,doors,mileage,price等等,总共65。Vehicle表,VehicleInterior, VehicleExterior, VehicleTechnical, VehicleExtra(与主Vehicle表一一对应)。假设我将有大约 500 万行(车辆)。
在SELECT一个WHERE条款:请问性能会更好,通过搜索(至少索引的这两种情况下IDs):
Vehicle 具有 65 列的表或Vehicle表与JOINS其他四个表(均具有 500 万行)以返回与Vehicle?(根据数据库引擎,考虑 PostgreSQL 和/或 MySQL)。
真的很感激您从以前的经验中可能获得的任何详细见解吗?
如果有的话,更新将很少见,并且选择将主要针对搜索结果列表的所有列(车辆详细信息页面)和主要信息(几列),实际上也许最好的解决方案是两个表:一个包含主要信息(很少列)和另一个表以及其余的列。
postgresql database-design partitioning postgresql-performance
可以在 PostgreSQL 中创建原子事务吗?
考虑我有这些行的表类别:
id|name
--|---------
1 |'tablets'
2 |'phones'
Run Code Online (Sandbox Code Playgroud)
并且列名具有唯一约束。
如果我尝试:
BEGIN;
update "category" set name = 'phones' where id = 1;
update "category" set name = 'tablets' where id = 2;
COMMIT;
Run Code Online (Sandbox Code Playgroud)
我越来越:
ERROR: duplicate key value violates unique constraint "category_name_key"
DETAIL: Key (name)=(tablets) already exists.
Run Code Online (Sandbox Code Playgroud) postgresql ×10
partitioning ×2
performance ×2
vacuum ×2
datatypes ×1
index ×1
json ×1
maintenance ×1
scalability ×1
sql-server ×1
transaction ×1
update ×1