Re: vacuum, performance, and MVCC

From: "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Csaba Nagy" <nagy(at)ecircle-ag(dot)com>
Cc: "Mark Woodward" <pgsql(at)mohawksoft(dot)com>, "PFC" <lists(at)peufeu(dot)com>, "Chris Browne" <cbbrowne(at)acm(dot)org>, "postgres hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: vacuum, performance, and MVCC
Date: 2006-06-23 14:46:47
Message-ID: E1539E0ED7043848906A8FF995BDA579011EFF56@m0143.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > This could be a solution... but then I'm not sure how well would do
> > queries which need the first 10 records based on some criteria which

> > does not include the group id. I guess limit queries across the
union
> > of the partitions don't work too well for now, and we do
> have such queries.

You would query the parent (no union). Do you need order by's ?
Without order by it is currently no problem.

Do we push the limit down to the separate tables when we have an
appropriate
index for the order by (that could be a TODO item)?
(You need a max of "limit" rows per child in the outer order)

Or we would need to implement an efficient index merge node
for order by queries on parent (and union all's) with low limits
and an appropriate index.

Selecting the oldest x rows from a time partitioned table is a frequent
problem
we need to work around here too (Informix db).

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-06-23 14:47:24 Re: Planning without reason.
Previous Message Hannu Krosing 2006-06-23 14:43:58 Re: vacuum, performance, and MVCC