Questions tagged «postgresql-8.4»

PostgreSQL 8.4版


3
如何在PostgreSQL 8.4中安装pgcrypto?
我正在使用Ubuntu Server 10.10,并且已使用安装了PostgreSQL 8.4 apt-get install postgresql。我想使用内置sha1()功能,但似乎必须先安装pgcrypto。但是我不知道如何安装。 没有pgcrypto,如果我尝试使用安装它apt-get install pgcrypto,我不找到以任何文件pgcrypto在我的系统(我想find / -name "pgcrypto*")。 如何安装pgcrypto,以便可以digest('word-to-hash','sha1')在数据库查询中使用该功能? 更新:我正在努力在另一台Ubuntu计算机上安装pgcrypto。使用sudo apt-get install postgresql-contrib-8.4如何安装软件包后,如何将其安装到当前的PostgreSQL数据库中?

2
如何创建索引以加快对表达式的聚合LIKE查询?
我可能在标题中提出了错误的问题。这是事实: 我的客户服务人员一直抱怨在基于Django的站点的管理界面上进行客户查找时响应速度慢。 我们正在使用Postgres 8.4.6。我开始记录慢速查询,并发现了这个罪魁祸首: SELECT COUNT(*) FROM "auth_user" WHERE UPPER("auth_user"."email"::text) LIKE UPPER(E'%deyk%') 此查询最多需要32秒才能运行。这是EXPLAIN提供的查询计划: QUERY PLAN Aggregate (cost=205171.71..205171.72 rows=1 width=0) -> Seq Scan on auth_user (cost=0.00..205166.46 rows=2096 width=0) Filter: (upper((email)::text) ~~ '%DEYK%'::text) 因为这是由Django ORM从Django Admin应用程序生成的Django QuerySet中生成的查询,所以我对该查询本身没有任何控制权。索引似乎是合理的解决方案。我尝试创建索引来加快速度,但是并没有什么不同: CREATE INDEX auth_user_email_upper ON auth_user USING btree (upper(email::text)) 我究竟做错了什么?如何加快查询速度?



3
使用PostgreSQL 8.4,如何将bytea转换为postgres中的文本值?
在我的应用程序中,我使用C代码将数据插入数据库中,因为从不可信来源收到的字符串已经使用PQescapeByteaConnlibpq库转义了。这工作得很好,即以八位字节格式生成字符串。参见以下示例, 输入字符串: \n\t\f\b\p\k\j\l\mestPrepared 输出字符串: \\012\\011\\014\\010pkjlmestPrepared 输出字符串将插入数据库中。现在,我使用JDBC以Java代码从数据库中检索该数据。我如何才能使字符串不转义回其原始值? 我想到了两种可能的方法, 更改数据库检索查询,并将此字段传递给postgres的任何String操作函数,即可以将bytea转换为文本的函数。 用Java代码进行解码。 我知道方法1会更有效。我已经尝试了这里列出的几乎所有功能,但是没有任何效果。请帮忙!! 我正在Linux机器上使用PostgreSQL的8.4版本。

7
分组或窗口
我有一种情况,我认为可以使用窗口函数解决,但我不确定。 想象一下下表 CREATE TABLE tmp ( date timestamp, id_type integer ) ; INSERT INTO tmp ( date, id_type ) VALUES ( '2017-01-10 07:19:21.0', 3 ), ( '2017-01-10 07:19:22.0', 3 ), ( '2017-01-10 07:19:23.1', 3 ), ( '2017-01-10 07:19:24.1', 3 ), ( '2017-01-10 07:19:25.0', 3 ), ( '2017-01-10 07:19:26.0', 5 ), …

1
PostgreSQL事务提交数小时
我遇到一个问题,从用户到我的PostgreSQL服务器有两个连接,它们已经运行了大约4个小时,并且处于提交状态已经有一段时间了(我一直在观察它至少1个小时) 。这些连接阻止了其他查询的运行,但它们本身并未被阻止。 这是有问题的两个连接。 postgres=# select * from pg_stat_activity where usename = 'xxxxx'; datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port -------+---------+---------+----------+---------+---------------+---------+-------------------------------+-------------------------------+-------------------------------+---------------+------------- 20394 | xxxxxx | 17509 | 94858 | xxxxx | COMMIT | f | …

1
在PostgreSQL 8.4中执行触发功能需要哪些特权?
在PostgreSQL 8.4中执行触发功能需要哪些特权? 似乎为角色设置的特权与执行触发功能无关紧要。我想我已经看到有一天执行触发器功能所需的特权是EXECUTE特权,但对于表的所有者而言,而不是执行触发触发器的触发器的实际角色。 我找不到说明这一点的文档部分,有什么帮助吗?

2
吐司表生长失控-FULLVAC无效
最近,我已经将PostgreSQL 8.2.11服务器升级到8.4,以便利用自动清理功能并与30台其他PGSQL服务器保持一致。这是由管理硬件的独立IT小组完成的,因此在其他任何升级方面我们没有太多选择(暂时不会看到9+)。该服务器存在于非常封闭的环境(隔离的网络,有限的root特权)中,并在RHEL5.5(i686)上运行。升级后,数据库每天不断增长,达到5-6 GB。通常,数据库总体上约为20GB;目前,它约为89GB。我们还有其他几个服务器,它们运行等效的数据库,并实际上通过第3方应用程序将记录彼此同步(其中一个我无法访问内部工作)。其他数据库大约应该是20GB。 运行下面的SQL,很明显特定表,尤其是TOAST表存在问题。 SELECT nspname || '.' || relname AS "relation", pg_size_pretty(pg_relation_size(C.oid)) AS "size" FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT IN ('pg_catalog', 'information_schema') ORDER BY pg_relation_size(C.oid) DESC LIMIT 20; 产生: 关系| 尺寸 ------------------------------------ + --------- pg_toast.pg_toast_16874 | 89 GB littles00.warmstates | …

2
在PostgreSQL 8.4中重新索引之前,是否应该总是进行VACUUM ANALYZE?
每天清晨,一个pgAgent作业都会从我的PostgreSQL 8.4数据库中的表B中刷新表A的内容。表A在91列中包含约140k记录,并具有两个索引-一个作为PRIMARY KEY的一部分,另一个在POINT PostGIS几何列上的GIST索引。 为了使过程更快一些,作业将删除几何列上的索引,然后删除表A中的记录并从表B中插入记录,然后重新创建索引。autovacuum守护程序在感觉良好时就可以完成所有工作(大约在十分钟后,通过比较作业状态和表状态的作业完成时间和autovacuum运行时间)。 在所有这些都发生之后,今天早上检查表时,表统计信息告诉我表大小为272MB,TOAST表大小为8192bytes,索引大小为23MB。这似乎很大,所以我在表上发出了REINDEX命令,索引大小降至9832kB。 我的问题是这样的: 为什么当从头开始重新构建索引(或至少是几何列索引)时,REINDEX会明显减少索引的大小?我应该确定在建立索引之前已经对表进行了清理/分析吗?这不是在主键上删除索引的一个因素吗?我想念什么?
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.