我有一个 PostgreSQL 表。select *很慢,但又select id好又快。我认为可能是行的大小非常大并且需要一段时间来运输,或者可能是其他一些因素。
我需要所有字段(或几乎所有字段),因此仅选择一个子集不是一个快速解决方案。选择我想要的字段仍然很慢。
这是我的表架构减去名称:
integer | not null default nextval('core_page_id_seq'::regclass)
character varying(255) | not null
character varying(64) | not null
text | default '{}'::text
character varying(255) |
integer | not null default 0
text | default '{}'::text
text |
timestamp with time zone |
integer |
timestamp with time zone |
integer |
Run Code Online (Sandbox Code Playgroud)
文本字段的大小可以是任意大小。但是,在最坏的情况下,不会超过几千字节。
postgresql performance size disk-space postgresql-performance
此查询获取您关注的人创建的帖子列表。您可以关注无限数量的人,但大多数人关注 < 1000 人。
使用这种查询方式,明显的优化是缓存"Post"id,但不幸的是我现在没有时间这样做。
EXPLAIN ANALYZE SELECT
"Post"."id",
"Post"."actionId",
"Post"."commentCount",
...
FROM
"Posts" AS "Post"
INNER JOIN "Users" AS "user" ON "Post"."userId" = "user"."id"
LEFT OUTER JOIN "ActivityLogs" AS "activityLog" ON "Post"."activityLogId" = "activityLog"."id"
LEFT OUTER JOIN "WeightLogs" AS "weightLog" ON "Post"."weightLogId" = "weightLog"."id"
LEFT OUTER JOIN "Workouts" AS "workout" ON "Post"."workoutId" = "workout"."id"
LEFT OUTER JOIN "WorkoutLogs" AS "workoutLog" ON "Post"."workoutLogId" = "workoutLog"."id"
LEFT OUTER JOIN "Workouts" AS "workoutLog.workout" ON "workoutLog"."workoutId" = "workoutLog.workout"."id"
WHERE
"Post"."userId" IN …Run Code Online (Sandbox Code Playgroud) postgresql performance index optimization postgresql-performance
我正在尝试优化一个查询,该查询查看一个大表(3700 万行),并有一个关于在查询中执行操作的顺序的问题。
select 1
from workdays day
where day.date_day >= '2014-10-01'
and day.date_day <= '2015-09-30'
and day.offer_id in (
select offer.offer_day
from offer
inner join province on offer.id_province = province.id_province
inner join center cr on cr.id_cr = province.id_cr
where upper(offer.code_status) <> 'A'
and province.id_region in ('10' ,'15' ,'21' ,'26' ,'31' , ...,'557')
and province.id_cr in ('9' ,'14' ,'20' ,'25' ,'30' ,'35' ,'37')
)
Run Code Online (Sandbox Code Playgroud)
WHERE日期范围的子句是否在子查询之前执行?将最严格的子句放在首位以避免其他子句的大循环,以便更快地执行是否是一种好方法?
现在查询需要很多时间来执行。
我有一个与性能相关的问题。假设我有一个名为 Michael 的用户。进行以下查询:
UPDATE users
SET first_name = 'Michael'
WHERE users.id = 123
Run Code Online (Sandbox Code Playgroud)
查询是否会实际执行更新,即使它被更新为相同的值?如果是这样,我该如何防止它发生?
我在 PostgreSQL 9.0.8 中有一个很大的对象表(15M+ 行),我想查询过时的字段。
出于可扩展性和并发性的目的,我想将查询除以数百万,并且我想获取具有几天前日期的 updated_at 字段的所有数据。
我已经在 100 万个 ID 上尝试了许多索引和查询,但使用 Heroku 的 Ronin 硬件似乎无法在 100 秒内获得性能。
我正在寻找我尚未尝试使其尽可能高效的建议。
尝试 #1
EXPLAIN ANALYZE SELECT count(*) FROM objects
WHERE (date(updated_at)) < (date(now())-7) AND id >= 5000001 AND id < 6000001;
INDEX USED: (date(updated_at),id)
268578.934 ms
Run Code Online (Sandbox Code Playgroud)
尝试 #2
EXPLAIN ANALYZE SELECT count(*) FROM objects
WHERE ((date(now()) - (date(updated_at)) > 7)) AND id >= 5000001 AND id < 6000001;
INDEX USED: primary key
335555.144 ms
Run Code Online (Sandbox Code Playgroud)
尝试 #3
EXPLAIN ANALYZE SELECT count(*) FROM …Run Code Online (Sandbox Code Playgroud) postgresql performance index partitioning postgresql-performance
假设我们有一个包含四列(a,b,c,d)相同数据类型的表。
是否可以选择列中数据中的所有不同值并将它们作为单个列返回,或者我是否必须创建一个函数来实现这一点?
postgresql performance postgresql-9.4 distinct postgresql-performance
2020-08-04 更新:
由于显然仍在定期查看此答案,因此我想提供有关情况的最新信息。我们目前正在使用带有表分区的 PG 11,timestamp并且可以轻松处理表中的数十亿行。仅索引扫描可以挽救生命,没有它就不可能。
使用 PostgreSQL 9.2,我在相对较大的表(200 多万行)上进行慢速查询时遇到问题。我没有尝试任何疯狂的事情,只是增加了历史价值。下面是查询和查询计划输出。
我的表布局:
Table "public.energy_energyentry"
Column | Type | Modifiers
-----------+--------------------------+-----------------------------------------------------------------
id | integer | not null default nextval('energy_energyentry_id_seq'::regclass)
prop_id | integer | not null
timestamp | timestamp with time zone | not null
value | double precision | not null
Indexes:
"energy_energyentry_pkey" PRIMARY KEY, btree (id)
"energy_energyentry_prop_id" btree (prop_id)
"energy_energyentry_prop_id_timestamp_idx" btree (prop_id, "timestamp")
Foreign-key constraints:
"energy_energyentry_prop_id_fkey" FOREIGN KEY (prop_id) REFERENCES gateway_peripheralproperty(id) DEFERRABLE INITIALLY DEFERRED
Run Code Online (Sandbox Code Playgroud)
数据范围从2012-01-01至今,新数据不断增加。prop_id外键中大约有 2.2k 个不同的值,均匀分布。
我注意到行估计值相差不远,但成本估计值似乎大了 …
postgresql performance index optimization postgresql-performance
我Postgresql 9.1在 Ubuntu 上运行。确切的 Postgresql 版本是9.1+129ubuntu1如我的包管理器所示。
我有 2 个正在使用的数据库,它们是从远程服务器使用的。
我希望记录执行时间较长的查询。所以我在/etc/postgresql/9.1/main/postgresql.conf文件中设置了以下参数
log_min_duration_statement = 10000
log_statement = 'mod'
Run Code Online (Sandbox Code Playgroud)
所以 Postgresql 会记录耗时超过 10 秒的查询。
但是当我reload配置 postgres 时,Postgresql 开始记录每个符合log_statement值的查询。我将持续时间设置为 100 秒以确保
log_min_duration_statement = 100000
Run Code Online (Sandbox Code Playgroud)
但是 Postgresql 会继续记录每个符合log_statement值的查询,而不管值是多少log_min_duration_statement。
设置log_statement为none似乎停止记录。
有什么我错过的配置吗?
postgresql performance logs postgresql-9.1 postgresql-performance
在 2015 年的 re:Invent 演讲中,AWS 提到真空不仅应该在更新或删除之后运行,而且还应该在插入之后运行。这是谈话的相关部分:
http://www.youtube.com/watch?v=tZXp19q8RFo&t=16m2s
据说即使块只收到插入,也必须对块进行一些清理,并且可以在第一次选择块时(减慢读取速度)或在真空期间进行清理。这是真的吗?如果是这样,究竟必须进行哪些清理工作?
是的,我知道数据规范化应该是我的首要任务(因为它是)。
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 ×10
performance ×9
index ×3
optimization ×2
partitioning ×2
disk-space ×1
distinct ×1
logs ×1
size ×1
update ×1
vacuum ×1