我正在尝试在一个命令行中更改同一架构下所有表的所有者。即:alter table schema_name.* owner to newowner。有没有办法做到这一点?
我有两个相同的服务器(在硬件方面),它们都是 windows server 2008 r2 的标准安装,安装了最少的软件(基本上是我的代码和必需的东西,如 jvm 等)。
在一台服务器上,我在第二台服务器 postgresql 9.1 上运行 sql server 2005。这两个服务器的性能差异是惊人的,它在 postgresql 上太糟糕了,我很后悔我最初对我老板说“让我们使用 postgresql 而不是支付 sql server 许可证”的演讲。我们正在讨论同一命令的 30 秒与 15 分钟的差异,这不仅仅是这个命令,它是我向其抛出的任何查询或命令。它们都有几乎相同的数据(记录以不同的顺序插入),并且两个数据库具有完全相同的结构/索引等。
但我希望这只是性能调整的问题。问题是,sql server 几乎使用了服务器上所有 32 gig 的 ram,而 postgresl 什么也没使用,绝对比 gig 少,尽管我实际上还没有详细了解它。
如何让 postgresql 使用 20 多场内存?这些服务器是专门为该数据库内容构建的,因此在我看来,数据库和支持进程未使用的任何内存都被浪费了。
我在 libpq 之上为PostrgreSQL制作了一个远程应用程序草案。它表现良好,但我已经描述了应用程序的一般功能。对于我产生的每个最终业务结果,我碰巧调用了类似 40 select 子句(通过 tcpip)的东西。
我有 SQL-Server 的回忆,提醒我尽量减少远程应用程序和数据库之间的交互次数。分析了我的选择后,我确实认为我可以SELECT使用连接将这个数字减少到 3 个子句。但我不记得SELECT在 another 中使用 a 的结果的语法SELECT。
例如:
SELECT * FROM individual
INNER JOIN publisher
ON individual.individual_id = publisher.individual_id
WHERE individual.individual_id = 'here I would like to use the results of a another select'
Run Code Online (Sandbox Code Playgroud)
另一个SELECT就是这样的:
SELECT identifier FROM another_table WHERE something='something'
Run Code Online (Sandbox Code Playgroud)
这是简化的表布局,针对不同的 item_types 拒绝了多次......(3 种完全不同的类型,因此如果优化了 3 个 SQL 查询)。
table passage
id_passage PK
business_field_passage bytea
table item
id_item PK
id_passage FK …Run Code Online (Sandbox Code Playgroud) 假设我有一个包含工作角色的表:
CREATE TABLE roles
(
"role" character varying(80) NOT NULL,
CONSTRAINT "role" PRIMARY KEY (role)
);
Run Code Online (Sandbox Code Playgroud)
假设我还有一个表、用户,并且每一行(一个特定用户)可以有任意数量的工作角色:
CREATE TABLE users
(
username character varying(12) NOT NULL,
roles character varying(80)[] NOT NULL,
CONSTRAINT username PRIMARY KEY (username)
);
Run Code Online (Sandbox Code Playgroud)
我应该确保每个成员都users.roles[]存在于roles.role 中。在我看来,我想要的是对每个成员的外键约束users.roles[],如果引用了roles.role。
这对于 postgres 似乎是不可能的。我是不是看错了?处理此问题的建议“正确”方法是什么?
也许这是一个愚蠢的初学者问题,但我在任何地方都找不到答案。我到处都读到了Transaction Isolation解决并发事务中数据可见性的方法。我关心的是单个事务中的行为。
如果我开始一个事务,插入一些数据,我是否能够在之后立即选择它们 - 仍然在同一个但未提交的事务中?如果是,在并发事务的情况下,这种行为是否可以像提到的事务隔离一样以类似的方式改变?
具体来说,我的目标是 PostgreSQL 9.4。
我的一台 PostgreSQL 服务器托管了几个 (1-3) 数据库,这些数据库接收恒定的数据流。数据不是特别结构化,它相当于当前时间和特定时刻的各种观察数据。数据速率相当高;一个数据库每天大约可以计算出 1 GB 的数据,而另一个数据库则大约是每天 1 GB 的数据。我不希望这个比率会增加。读取性能的优先级要低得多,目前是可以接受的。
在日志中,我有这条消息:
LOG: checkpoints are occurring too frequently (15 seconds apart)
HINT: Consider increasing the configuration parameter "checkpoint_segments".
Run Code Online (Sandbox Code Playgroud)
该值当前设置为 16,这是由 提供的pgtune。
我应该考虑哪些设置来提高写入性能?我宁愿保持尽可能多的安全。考虑到传入的数据量,只要大部分数据完好无损,我可以接受在故障中丢失一些最近的数据。
编辑:我现在使用 PostgreSQL 9.0,但我计划升级到 9.1。我不会发布硬件细节,因为虽然我承认它们的重要性,但我最终将需要在具有非常不同硬件的几台机器上进行这种优化。如果硬件对答案至关重要,请给我一般信息,以便我可以将答案应用于具有不同硬件配置的机器。
我使用的是 PostgreSQL 9.2,当我启动系统 (Kubuntu) 时它会自动运行。
我怎样才能避免这种情况?
我需要手动启动它,我不希望它在无人看管的情况下启动,因为我需要查看控制台。
VACUUM通常不会将磁盘空间返回给操作系统,除非在某些特殊情况下。
从文档:
VACUUM删除表和索引中的死行版本并标记可用空间以供将来重用的标准形式。但是,它不会将空间返回给操作系统,除非在表末尾的一个或多个页面完全空闲并且可以轻松获得排他表锁的特殊情况下。相比之下,VACUUM FULL通过编写一个没有死空间的完整新版本的表文件来主动压缩表。这最大限度地减少了表的大小,但可能需要很长时间。它还需要额外的磁盘空间用于表的新副本,直到操作完成。
问题是:如何实现这个数据库状态one or more pages at the end of a table become entirely free?这可以通过 完成VACUUM FULL,但我没有足够的空间来实现它。那么还有没有其他可能呢?
我有巨大的 postgres 表(10GB 数据 - 160M 记录)。表是静态的,没有对其执行写操作。我想复制它,执行写入,重新索引它,然后使用单个快速事务删除旧的并将新的重命名为原始名称。
复制如此巨大的表的最快方法是什么?
我在本地安装了 9.1 数据库,其中有几个表有 cca。300 条 mio 记录,数据库增长到大约 20 GB。之后我发出delete from命令从中删除所有记录(我应该使用truncate,但我不知道)。所以我对我的数据库进行了完全真空以回收磁盘空间,但这无济于事。我的问题看起来与这个相同,但没有提供解决方案。我已经检查了这个线程和关于“恢复磁盘空间”的文档,但仍然找不到解决方案。我使用此代码获取所有表的大小
SELECT nspname || '.' || relname AS "relation",
pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT IN ('pg_catalog', 'information_schema')
AND C.relkind <> 'i'
AND nspname !~ '^pg_toast'
ORDER BY pg_total_relation_size(C.oid) DESC
LIMIT 15;
Run Code Online (Sandbox Code Playgroud)
但是总共不到 1GB
SELECT pg_database.datname, pg_size_pretty(pg_database_size(pg_database.datname)) AS size FROM pg_database
Run Code Online (Sandbox Code Playgroud)
仍然显示大约 20 GB。任何建议非常感谢。
postgresql ×10
disk-space ×2
array ×1
join ×1
maintenance ×1
memory ×1
performance ×1
permissions ×1
select ×1
transaction ×1
ubuntu ×1
vacuum ×1