ll as your results
(otherwise two days later you won't remember which test obtained
what result)
HTH
- - andreas
- --
Andreas Haumer | mailto:[EMAIL PROTECTED]
*x Software + Systeme | http://www.xss.co.at/
Karmarschgasse 51/2/20 | Tel: +43-1-
small ones it looks like we don't
need or want partitioned tables anyway)
Perhaps I can hide this logic in some stored procedures
(I already have several stored procedures to handle
automatic and transparent creation of child tables on
INSERTs anyway...)
- - andreas
- --
Andreas Haumer
02:00:00+01'::timestamp with time
zone))
Total runtime: 0.176 ms
(10 rows)
Here, two child tables are involved (t_mv_200512 and t_mv_200601)
and the query only uses those two, even without cast of the constants
in the where clause.
- - andreas
- --
Andreas Haumer | mailto:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Guillaume Cottenceau schrieb:
> Andreas Haumer writes:
[...]
>
>> Now my question is: Does the query planner in the case of partitioned tables
>> really have to scan all indexes in order to get the next timestamp smaller
>
th time zone))
Total runtime: 394.384 ms
(49 rows)
Now my question is: Does the query planner in the case of partitioned tables
really have to scan all indexes in order to get the next timestamp smaller
(or larger) than a given one?
There are check conditions on all table partitions like this:
