On Tue, 2007-05-08 at 13:41, Fei Liu wrote:
> Scott Marlowe wrote:
> > On Thu, 2007-05-03 at 21:37, Merlin Moncure wrote:
> >
> >> On 5/3/07, Fei Liu <[EMAIL PROTECTED]> wrote:
> >>
> >>> Hello, Andreas, I too am having exactly the same issue as you do.
> >>> Comparing my partitioned and pl
Scott Marlowe wrote:
On Thu, 2007-05-03 at 21:37, Merlin Moncure wrote:
On 5/3/07, Fei Liu <[EMAIL PROTECTED]> wrote:
Hello, Andreas, I too am having exactly the same issue as you do.
Comparing my partitioned and plain table performance, I've found that
the plain tables perform about 25
On 5/4/07, Scott Marlowe <[EMAIL PROTECTED]> wrote:
On Thu, 2007-05-03 at 21:37, Merlin Moncure wrote:
> On 5/3/07, Fei Liu <[EMAIL PROTECTED]> wrote:
> > Hello, Andreas, I too am having exactly the same issue as you do.
> > Comparing my partitioned and plain table performance, I've found that
>
On Thu, 2007-05-03 at 21:37, Merlin Moncure wrote:
> On 5/3/07, Fei Liu <[EMAIL PROTECTED]> wrote:
> > Hello, Andreas, I too am having exactly the same issue as you do.
> > Comparing my partitioned and plain table performance, I've found that
> > the plain tables perform about 25% faster than parti
On 5/3/07, Fei Liu <[EMAIL PROTECTED]> wrote:
Hello, Andreas, I too am having exactly the same issue as you do.
Comparing my partitioned and plain table performance, I've found that
the plain tables perform about 25% faster than partitioned table. Using
'explain select ...', I see that constraint
Andreas Haumer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I'm currently experimenting with PostgreSQL 8.2.4 and table
partitioning in order to improve the performance of an
application I'm working on.
My application is about managing measurement values (lots of!)
I have one table
Wait, rereading the original queries I seem to have misunderstood something.
The individual parts of the partitioned tables are being accessed in timestamp
order. So what's missing is some way for the optimizer to know that the
resulting append results will still be in order. If it knew that all t
On Mon, Apr 30, 2007 at 03:29:30PM +0200, Andreas Haumer wrote:
> This already gives a row matching the given WHERE clause.
> It makes no sense to scan the other tables, as the query
> asks for one row only and all the other tables have timestamps
> larger than all the timestamps in table t_mv_2006
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Tom Lane schrieb:
[...]
> As already pointed out, this is only going to be able to exclude
> partitions that are strictly after the limit-time, since you have no
> WHERE clause that excludes anything before. Can you set a reasonable
> upper bound
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Neil Peter Braggio schrieb:
> Just cast the value in the WHERE clause:
>
> select ts from mwdb.t_mv where zr=3622 and ts > '2006-01-01 00:00:00'
> ::TIMESTAMP order by ts asc limit 1;
>
> This search only into the right partitioned tables if you
"Guillaume Cottenceau" <[EMAIL PROTECTED]> writes:
> I think this is the last claimed point which is incorrect. Pg has
> no general guarantee the partitions actually create a disjoint
> set, even with the CHECK constraints. Pg can only optimize by
> avoiding scanning the partitions inside which no
Andreas Haumer <[EMAIL PROTECTED]> writes:
> A simple example: Get the timestamp of a measurement value for time
> series 3622 which is right before the measurement value with time
> stamp '2007-04-22 00:00:00':
> testdb_std=> select ts from mwdb.t_mv where zr=3622 and ts < '2007-04-22
> 00:00:00
Just cast the value in the WHERE clause:
select ts from mwdb.t_mv where zr=3622 and ts > '2006-01-01 00:00:00'
::TIMESTAMP order by ts asc limit 1;
This search only into the right partitioned tables if you build the rules
based in the ts field.
Neil Peter Braggio
[EMAIL PROTECTED]
On 4/
Andreas Haumer writes:
> > Well, how can the planner know inside which partition the wanted
> > row is? There might be no data, say, inside a couple of
> > partitions in the past before finding the wanted row, in which
> > case 3 partitions in the past must be scanned.
> >
>
> I think the plann
Andreas Haumer wrote:
I think the planner could do the following:
a) It could make a better decision in which direction to scan
the partitions (depending on sort order involved in the query)
b) It could stop scanning as soon as there can not be any further
resulting row according to the
-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
>> (or larger) than a gi
Andreas Haumer writes:
[...]
> testdb_part=> explain analyze select ts from mwdb.t_mv where zr=3622 and ts <
> '2007-04-22 00:00:00' order by ts desc limit 1;
>
> QUERY PLAN
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I'm currently experimenting with PostgreSQL 8.2.4 and table
partitioning in order to improve the performance of an
application I'm working on.
My application is about managing measurement values (lots of!)
I have one table "t_mv" which stores all
18 matches
Mail list logo
