"Matt Klinker" <[EMAIL PROTECTED]> writes:
> --Joined View:
> CREATE OR REPLACE VIEW directory_listing AS
> SELECT school.id, school.name, school.description, 119075291 AS
> listing_type_fid
>FROM school
> UNION ALL
> SELECT company.id, company.name, company.description, 119074833 AS
> listin
"kevin kempter" <[EMAIL PROTECTED]> writes:
> that the planner wants to do a sequential scan on each partition. We do have
> "constraint_elimination = on" set in the postgresql.conf file.
"constraint_exclusion" btw.
> myDB=# explain SELECT min(logdate) FROM part_master;
Er, yeah. Unfortunat
kevin kempter wrote:
Hi List;
Sorry if this is a dupe, my first post never showed up...
I'm having some performance issues with a partitioned table. We have a
VERY large table that we've partitioned by day.
Unfortunately, that is the defined behavior in this case. From 5.9.6 of
the manual
Hi List;
Sorry if this is a dupe, my first post never showed up...
I'm having some performance issues with a partitioned table. We have a
VERY large table that we've partitioned by day.
Currently we have 17 partitions - each partition table contains >
700million rows.
One of the things we
I'm sorry for the "fan-dance", it was not my intention to make it difficult
but actually simpler in leaving out the finer details - lesson learned.
Below you'll find create scripts for all tables and views invlolved. Also
I've included the explain text for both queries when ran on the 8.3 database
On Fri, 4 Apr 2008, Ow Mun Heng wrote:
select * from table
where A=X
and B = Y
and C = Z
and D = AA
and E = BB
With that kind of WHERE condition, Postgres will use a Bitmap Index Scan
to combine your indices. If, however, postgres notices while looking at
the statistics gathered during A
On Fri, 4 Apr 2008, Ow Mun Heng wrote:
select * from table
where A=X
and B = Y
and C = Z
and D = AA
and E = BB
This may not be the answer you're looking for, but if you create a
multi-coloumn index, it should be able to make your query run fast:
CREATE INDEX foo ON table (A, B, C, D, E);
It
