如何动态地从 plpgsql 函数中的记录中寻址一列?
在以下代码段中,我可以访问一个变量entity.colname,该变量包含应在 IF 控制结构中检查的列。我正在研究如何foobar用entity.colname. 这在 plpgsql 中可能吗?
IF NEW.foobar IS NULL THEN
RAISE EXCEPTION '% cannot be null', foobar;
END IF;
Run Code Online (Sandbox Code Playgroud)
这是可以但行不通的事情。
IF NEW.entity.colname IS NULL THEN
RAISE EXCEPTION '% cannot be null', entity.colname;
END IF;
Run Code Online (Sandbox Code Playgroud)
上面的例子只是为了说明我想要实现的目标,不要判断功能。:)
我正在使用 PostgreSQL 9.1。
我目前正在使用\timing onPostgres 进行一些简单的性能测试。我想运行许多查询并将计时结果通过管道传输到文件。但是,我尝试过的所有选项(\o、\l和它们的命令行等效项)仅将查询结果通过管道传输到文件。该Time: 1.234 ms消息不会被写入文件。
有什么方法可以将引起的计时输出通过管道\timing on传输到文件中,还是必须选择其他方法来执行测试?
我现在正在使用 Postgres 8.4。性能已开始成为一个问题,因为我们的表的规模和我们在复杂的查询已经长大,所以我开始寻找到一些性能调优,但我不是一个专家在所有的这些东西。
我注意到手册多次提到提高性能的好方法是为查询计划器使用更好的成本常量,但它也说没有简单的方法来确定要使用的成本常量。
我认为常量现在可能有问题,因为估计成本似乎不是实际执行时间的稳定倍数 - 即使在最近运行 VACUUM ANALYZE 之后,它也会从 30 倍到大约 600 倍变化。(我不知道这是否是检查常量是否设置良好的有效方法,如果我错了,请纠正我)
所以,我想为查询规划器设置更好的常量。我该怎么做?我应该随机上下调整直到看起来更快,还是我应该做一些更正式的事情?是否有任何基于硬件或其他方面的指导方针?
顺便说一句,如果答案是“别担心,首先要改进其他事情会更重要”,那很好 - 对于我的实际案例,我会处理其他事情。但对于其他人的缘故,它仍然是好知道怎么一会提高常量,如果一切已经得到了改善。
昨天我们讨论了性能和可恢复性,我意识到虚拟化环境可以给我带来多少好处 - 但由于我对性能有点怀疑,所以我在这里问。它可能是特定于 GIS 的,但是在 gis 用户那里,他们说这是特定于数据库的......;)
数据库服务器是否会因虚拟化而遭受严重的性能损失?我不了解这项技术的最后细节,但不知何故,它更像是一个“黑匣子”,需要通过硬件进行处理。磁盘访问以及 PostGIS 为我们提供的所有技巧是否会被授予?(聚类、索引等) - 碎片聚类就像没有聚类!
最大的优势是可维护性和可扩展性。如果发生严重的硬件故障,我可以在几分钟内甚至实时迁移到另一台物理机器。
谁有经验,可以给我指点关于这个主题的好的网站或文献?我记得上次 fossgis 中的一些事情以及 ESXi 和本机服务器上的一些内部基准测试,不知何故我无法确定它是否好。
我有一个 Rails 应用程序,有 4 个 Unicorn 工人。如何确定我应该使用什么 postgresql 数据库池大小?
如果我有 6 个应用程序连接到这个 postgres 数据库,那会不会有太多连接?我应该改用 pgbouncer 吗?如果是这样,为什么?
我最近开始在我的 rails 应用程序中使用 PostgreSQL。
我正在寻找 PostgreSQL 数据库的 SQL GUI(适用于 Mac)。
有什么比 pgadmin3 更好的吗?
我在 Windows Server 2008 R2 上运行 PostgreSQL 9.1。我通过修改 postgresql.conf 文件启用了将 SQL 语句记录到 stderr 日志,但现在我似乎无法在不关闭所有日志记录的情况下禁用日志记录。服务器通过 pg_ctl reload 发送 SIGHUP 信号,并且在每次尝试修复此问题后服务已重新启动。重新启动整个机器似乎也没有帮助。
我当前的 postgresql.conf 中的特定行应该已经完成了这个,但不是:
log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log'
#debug_print_parse = off
#debug_print_rewritten = off
#debug_print_plan = off
#debug_pretty_print = on
#log_checkpoints = off
#log_connections = off
#log_disconnections = off
#log_duration = off
#log_error_verbosity = default
log_hostname = on
log_line_prefix = '%t %a %u %r '
#log_lock_waits = off
log_statement = 'none'
#track_activities = on …Run Code Online (Sandbox Code Playgroud) 我正在尝试执行使用 plpgsql 在循环中重复调用的查询 - 循环遍历另一个表(命名坐标),其中包含网格的左上角和右下角纬度/经度坐标,我传递左上角和右下角纬度/ 经度值输入我的 CTE,以便显示在给定两个时间戳的这些坐标内发出的请求量(每小时)-。但是,我无法显示 CTE 的结果,并且收到以下错误消息:
ERROR: query has no destination for result data
HINT: If you want to discard the results of a SELECT, use PERFORM instead.
CONTEXT: PL/pgSQL function "inline_code_block" line 6 at SQL statement
Run Code Online (Sandbox Code Playgroud)
为了使整个查询根据需要工作,我应该在这里更改什么?我的代码如下:
DO $$
<<outer_scope>> DECLARE
coords RECORD;
BEGIN
FOR coords IN SELECT topleftlat, topleftlon, bottomrightlat, bottomrightlon FROM coordinates LOOP
WITH cal AS (
SELECT generate_series('2011-02-02 00:00:00'::timestamp ,
'2012-04-01 05:00:00'::timestamp ,
'1 hour'::interval) AS stamp
),
qqq AS (
SELECT date_trunc('hour', …Run Code Online (Sandbox Code Playgroud) 我很难弄清楚如何准确实现“如果未找到则插入”功能。考虑以下。
我们有一个名为artist2 列的表,(name, id)其中name是唯一id键,是串行主键。这是一个人为的例子,但它说明了我的问题:
SESSION A SESSION B
1. SELECT id FROM artist
WHERE name = 'Bob';
2. INSERT INTO artist (name)
VALUES ('Bob')
3. INSERT INTO artist (name)
VALUES ('Bob')
4. code that users 'Bob'
(e.g., a FK to Bob's ID)
5. ??? Bob already exists, but we
can't find it
4. COMMIT
Run Code Online (Sandbox Code Playgroud)
会话 B 开始尝试找到一个artist叫 Bob 的人,但失败了。但是,会话 A 然后创建了 Bob。会话 B 尝试插入名为 Bob 的艺术家,但由于违反主键而失败。但这是我不明白的一点——如果我将操作 3 更改 …
我观察到一个奇怪的情况,随着时间的推移,查询(下面解释的查询组合)的性能会下降,这意味着在测试开始时(几分钟)查询的时间是 2 毫秒,然后第二天它变成了 15 毫秒然后是 30 毫秒后的一天。
通过查询,我在这里指的是以下任一者的组合:
我想知道可能是什么原因,或者我应该考虑设置配置文件中的哪些设置以及如何设置?我在设置了数据库但未添加主键的 Ubuntu 机器上观察到了这个问题。另一方面,在我开发的 Win 上没有观察到(它在 7 天内平均每个查询 3ms 持续运行)。
我注意到在新数据库(在 Ubuntu 上)中,任何表上都没有主键,这与我开发的数据库相反。缺少主键是否会对此类查询产生负面影响?
我想我会同时问这个问题,因为我正在将我的整个数据库从我的开发机器移到测试机器上。
开发时我使用 PostgreSQL 8.4(CPU:Intel i7 740QM,RAM:6GB),测试时使用 PostgreSQL 9.1(CPU:Intel i3-2100,RAM:3.8GB)。
更新: autovacuum相关参数:
#autovacuum = on
#log_autovacuum_min_duration = -1
#autovacuum_max_workers = 3
#autovacuum_naptime = 1min
#autovacuum_vacuum_threshold = 50
#autovacuum_analyze_threshold = 50
#autovacuum_vacuum_scale_factor = 0.2
#autovacuum_analyze_scale_factor = 0.1
#autovacuum_freeze_max_age = 200000000
#autovacuum_vacuum_cost_delay = 20ms …Run Code Online (Sandbox Code Playgroud) postgresql ×10
performance ×3
plpgsql ×2
concurrency ×1
dynamic-sql ×1
logs ×1
mac-os-x ×1
pgpool ×1
postgis ×1
transaction ×1
vmware ×1