我们当前正在从 PostgreSQL apt 存储库安装 Postgresql。有没有办法让“apt-get install postgresql-9.6”在设置集群时使用 --data-checksums 选项?
或者我们需要以不同的方式安装 Postgresql 吗?
名为“messages”的表中有大约 5000 万行。问题是,即使使用索引,特定查询也运行得非常慢。我的背景更多是 Mysql,所以我更像是 Postgres (9.5) 的新手。任何解决此表查询缓慢问题的建议或帮助将不胜感激。
\n\n该表的结构如下:
\n\nmydatabase=# \\d+ messages\n\n\n id | integer | not null default nextval(\'messages_id_seq\'::regclass) | plain | | \n conversation_id | integer | | plain | | \n user_id | integer | | plain | | \n content | text | | extended | | \n attached_photos | text | | extended | | \n attached_video | text | | extended | | \n status | character varying(255) | | extended | | …Run Code Online (Sandbox Code Playgroud) 我有一个运行 Ruby on Rails 的应用程序,标准的,一点也不花哨。今天,当我在 Postgresql 中更改密码时,我发现该应用程序仍在使用旧凭据运行。这使我有时间使用新的数据库凭据滚动重新启动应用程序。开放连接仍然有效,因为是使用旧凭据进行身份验证的。Postgres 将使这些连接保持活动状态多久?我假设客户端必须重新进行身份验证后必须经过一段时间。我在哪里可以找到更多相关信息?一些设置?试图在https://www.postgresql.org/docs/9.5/static/runtime-config-connection.html上找到一些东西,但仍然不知道它的详细工作原理。
使用 Java 和 JDBC,我将字符串存储到 Postgres 中的 JSONB 列中。插入时效果很好。
检索值时,Java 内存不足,因为我检索的数据量较大,并且每个 json/字符串大约为 1MB。我想做的是编写这样的查询:
SELECT compress( myJsonColumn ) FROM myTable WHERE ...
Run Code Online (Sandbox Code Playgroud)
我在 Postgres 中查找了一些压缩方法,但没有找到。任何指示将不胜感激。谢谢。
澄清:澄清一下,我不想压缩数据库中的数据。我认为 Postgres 会优雅地处理这个问题,我主要关心的是 java-heap-space。
我的架构中有三个组件。
最近,我们注意到许多 Rails 迁移最终在生产中导致死锁/冻结我们的应用程序+数据库。初步调查显示,这可能是由于应用程序并发访问以及对读取量非常高的表进行迁移造成的。
探索复制的 PG 设置(也许是主从)是否有意义,其中所有写入和迁移都针对主服务器执行,所有大容量读取都针对从服务器执行?
当 ALTER TABLE 语句复制到从站时,PG 的行为如何?从机是否也获取相同的表锁?复制能解决我们目前面临的问题吗?
在 Linux (Centos) 上执行 postgres 小版本升级的推荐方法是什么?我正在考虑从 9.5.4 升级到 9.5.5。
我有 4 张桌子(实际上我还有很多想要做的事情......但这就是我开始的地方)。
distr_catalogs: 有很多distr_catalog_brands,distr_catalog_system_typesdistr_catalog_brands: 属于distr_catalogsdistr_catalog_system_types: 属于distr_catalogsbrand_catalog_sections: 属于distr_catalog_brands,distr_catalog_system_types我想创建一个物化视图,其列是:
catalog_id | catalog_name | brand_ids | system_type_ids | catalog_sections
Run Code Online (Sandbox Code Playgroud)
catalog_id&catalog_name从桌子上distr_catalog来brand_ids包含与目录相关的品牌 ID 数组system_type_ids保存与目录相关的系统类型 ID 的数组catalog_sectionsbrand_ids包含与和相关的品牌目录部分 ID 的数组system_type_ids除了最后一个之外,我可以做所有的事情:
CREATE MATERIALIZED VIEW catalog_system_brands AS
select dc.id as catalog_id, dc.catalog_name,
ARRAY(SELECT brand_id FROM distr_catalog_brands WHERE distr_catalog_id = dc.id) as brands,
ARRAY(SELECT id FROM distr_catalog_system_types WHERE display_status …Run Code Online (Sandbox Code Playgroud) 我正在将 Web 应用程序从 SqlServer 迁移到 PostgreSQL,并且我正在尝试找出要替换的类型datetime2。
一般的建议似乎是总是使用timestamptz,以及从不使用timestamp。给出的原因往往是时间戳和timestamptz存储相同(因此没有性能损失)并timestamptz自动转换为连接的时区。在 Rails 和 PostgreSQL 中完全忽略时区 | 堆栈溢出
不幸的是,我的旧版 .NET 代码库与日期时间非常不一致,我们通常以 UTC 进行渲染,而不管用户时区如何。最近的代码一直在使用 NodaTime 及其Instant类,但我们很少需要处理时间并且仅显示日期已经“足够接近”。然而,我对正确使用 NodaTime 的理解是尽可能晚地将 转换Instant为,而不是在数据库中。LocalDateTime
除此之外,我不完全确定 Postgres 如何知道“当前用户”的正确时区。我知道您可以专门将时区设置为会话参数SET TIME ZONE 'UTC';,您是否希望为每个连接执行此操作以适合“当前用户”?如果是这样,每当从连接池检索连接时都会重置它吗?我还看到 Npgsql 能够为连接字符串设置时区,如果是针对每个用户,这可能是不合适的?
所有这些使我认为最好的选择是用于timestamp所有日期时间,并使用应用程序逻辑转换为本地日期时间。我想另一个选择是用于timestamptz所有日期时间,强制连接在连接字符串中使用 UTC,并使用应用程序逻辑转换为本地日期时间。但是我担心 Postgres 会在 UTC 和 UTC 之间进行无操作转换时执行额外的工作。
TLDR:timestamptz如果应用程序始终插入/读取 UTC 并转换为本地日期时间本身,这仍然是首选吗?
我想创建一个对表进行操作的函数,例如
create or replace function test(t table)
returns void language plpgsql as
$func$
begin
select * from t limit 10;
end;
$func$
Run Code Online (Sandbox Code Playgroud)
然后,我可以使用任何表名调用该函数,例如
select test(myTable);
Run Code Online (Sandbox Code Playgroud)
我该怎么做这样的事情?
我有一个用于存储事件的表,该表timestamptz使用按月按列分区PARTITION BY RANGE。
目前有 5 个分区,每个分区包含一个月的跨度,从 开始FOR VALUES FROM ('2018-01-01') TO ('2018-02-01')到结束FOR VALUES FROM ('2018-05-01') TO ('2018-06-01')。
大多数数据都是以线性且可预测的方式输入的。但是,事件由报告事件的应用程序消耗,并且我确实必须允许随时输入过去的事件 - 其时间戳可能早于2018-01-01,甚至是未来的事件(例如预计的费用)发生在未来的某个时间)。
我计划为过去的事件创建一个分区,这些事件的跨度将超过一个月,因为预计不会有太多此类事件。
我不确定对于尚未存在分区的未来事件的最佳方法是什么。
有没有办法获取我可以在现有分区中存储的最小/最大值?如果没有,我可以创建一个参考表来存储这些值,但我宁愿不必维护它。
我应该创建一个触发器来检查插入的每一行(看起来很昂贵)吗?我应该捕获插入错误并一次处理这些错误吗?
运行于PostgreSQL 10.3.
postgresql ×10
plpgsql ×2
compression ×1
datetime ×1
ddl ×1
jdbc ×1
join ×1
partitioning ×1
performance ×1
replication ×1
slow-log ×1
subquery ×1
timestamp ×1
ubuntu ×1
upgrade ×1