The following bug has been logged on the website:
Bug reference: 7580
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Linux
Description:
create table t1 as select id from generate_series(1,10) as g(id);
The following bug has been logged on the website:
Bug reference: 7581
Logged by: William Dauchy
Email address: wdau...@gmail.com
PostgreSQL version: 9.2.1
Operating system: Linux
Description:
I tried to compile pgsql9.2 with the following options: --with-blocksize=16
maxim.bo...@gmail.com writes:
create table t1 as select id from generate_series(1,10) as g(id);
create table t2 as select id from generate_series(1,10) as g(id);
alter table t1 add primary key (id);
alter table t2 add primary key (id);
analyze t1;
analyze t2;
explain select * from
My Server has 4GB mem and OS is Windows 2008 R2.
I downloaded the latest version,and the cost of not in is much higher than
that of not exist.Please see attachment for detail.
As the time of query is very long,I didn't get the explain analyze result.
I think the id columns of table a and b are
I downloaded the latest version,and the cost of not in is much higher than
that of not exist. please see attachment for detail.
As the time of query is very long,I didn't get the explain analyze result.
I think the id columns of table a and b are not null, so the query of not in
and not exists
l...@tom.com writes:
I think the id columns of table a and b are not null, so the query of not
in and not exists are equal,they should use similar plans.
NOT IN and NOT EXISTS are *not* equivalent. Per SQL standard, NOT IN
has different (and usually not very desirable) behavior with NULL
Test database have a bit unusual tablespace layout:
main tablespace partition was mounted inside data directory of the old
cluster...
E.g.:
data directory - /var/lib/postgresql/9.2/main
main tablespace (another partition mount point) -
/var/lib/postgresql/9.2/main/largedb
Can you
I am seeing the situation where the reported flush location for the sync
standby (standby1 below) is *behind* the reported current xlog location
of the primary. This is Postgres 9.1.5 , and I was under the impression
that transactions initiated on the master do not commit until the
