Yep I ran into the exact same problem.
My solution was to create a pl/pgsql function to query the child tables: (
http://archives.postgresql.org/pgsql-performance/2008-11/msg00284.php)
If you find a better solution please share.
-Greg Jaman
On Wed, Sep 2, 2009 at 1:15 PM, Kenneth Cox wrote
ght select at run time.
For the same reason, "stable" functions such as CURRENT_DATE must be
avoided."
I think this applies to both your query and the CHECK statement in the table
definition.
-Greg Jaman
On Wed, Sep 2, 2009 at 8:05 AM, Kevin Kempter wrote:
> On Wednesday 02 S
ondiste.py londiste.ini subscriber add 'public.Data__WI'
On Thu, May 28, 2009 at 11:56 AM, Greg Jaman wrote:
> I currently have a database doing something very similar. I setup
> partition tables with predictable names based on the the data's timestamp
> week number eg: (
I currently have a database doing something very similar. I setup partition
tables with predictable names based on the the data's timestamp week number
eg: (Data__WI).
I have a tigger on the parent partition table to redirect data to the
correct partition( tablename:='Data_' || to_char('$NEW
x_ts is NULL OR childres.ts > max_ts THEN
max_ts:= childres.ts;
max_dataID:= childres."dataID";
END IF;
END IF;
END LOOP;
return max_dataID;
END;
$$
language 'plpgsql';
On Wed, Nov 26, 2008 at 4:48 PM, Gregory Stark <
find the max value. The query plan for the partitions uses a combination of
bitmap heap scans and index scans.
Why would the query plan choose to use a bitmap heap scan after bitmap index
scan or is that the best choice? (what is it doing?) and what can I do to
speed up this query?
As a sanity check I did a union query of all partitions to find the max(ts).
My manual union query executed in 13ms vs the query against the parent table
that was 85,188ms!!!.
Greg Jaman
