The following bug has been logged on the website:
Bug reference: 8172
Logged by: Barascu Tudor
Email address: tudorbara...@yahoo.com
PostgreSQL version: 9.2.4
Operating system: Centos 6.4 kernel 2.6.32-358.6.2.el6.x86_64
Description:
In pg_hba.conf I have the followi
I use PostgeSQL 9.1 32-bit on Windows 7 Professional with Active Directory as
LDAP.
I have following configration in pg_hba.conf:
host all all all ldapldapserver=192.168.155.157
ldapbinddn="CN=aa,OU=b,DC=,DC=" ldapbindpasswd=**
ldapbasedn="DC=,DC=" l
The SARS_ACTS table currently has 37,115,515 rowswe have indexed: idx_sars_acts_acts_run_id ON SARS_ACTS USING btree (sars_run_id)we have pk constraint on the SARS_ACTS_RUN table; sars_acts_run_pkey PRIMARY KEY (id )serverdb=# explain select count(*) as y0_ from SARS_ACTS this_ inner join SARS_ACTS
On Tue, May 21, 2013 at 3:54 PM, wrote:
> The SARS_ACTS table currently has 37,115,515 rows
>
> we have indexed: idx_sars_acts_acts_run_id ON SARS_ACTS USING btree
> (sars_run_id)
> we have pk constraint on the SARS_ACTS_RUN table; sars_acts_run_pkey PRIMARY
> KEY (id )
>
> serverdb=# explain sel
Thanks Jaime for your feedback, I did add an index on SARS_ACTS_RUN.ALGORITHM column but it didn't improve the run time. The planner just changed the "Filter:" to an "Index Scan:" improving the cost of the Seq Scan on the sars_acts_run table, but the overall run time remained the same. It seems lik
The following bug has been logged on the website:
Bug reference: 8174
Logged by: David Johnston
Email address: pol...@yahoo.com
PostgreSQL version: 9.0.13
Operating system: Ubuntu Linux 10.04
Description:
Having performed a "pg_dump --schema_only --format=c" of a data
