On Sun, Mar 21, 2010 at 1:30 PM, Vick Khera wrote:
> Like the two Scott M's recommended, figure out your usage patterns and
> partition across those vectors to optimize those searches. I would
> not worry about optimizing the insert pattern.
Note that once the partitions get small enough, on big
Vick Khera wrote:
You really *never* delete this data? I would suspect then that having
a partitioning scheme where the number of partitions can grow over
time is going to be important to you.
he said a new table is created each day, but nothing about these daily
tables being partitions in
On Sat, Mar 20, 2010 at 4:47 AM, Deepa Thulasidasan
wrote:
> transaction table to grow by 10 times in near future. In this regard, we
> would like to know if this same structure of the transaction table and the
> indexing would be sufficient for quick retrivel of data or do we have to
> partit
On Sat, Mar 20, 2010 at 5:26 AM, Scott Marlowe wrote:
> On Sat, Mar 20, 2010 at 2:47 AM, Deepa Thulasidasan
> wrote:
> > Dear All,
> >
> > I have a query in postgresql if any one can support.
> >
> > A transaction table in a vehicle tracking application is inserted with
> the current position of
On Sat, Mar 20, 2010 at 2:47 AM, Deepa Thulasidasan
wrote:
> Dear All,
>
> I have a query in postgresql if any one can support.
>
> A transaction table in a vehicle tracking application is inserted with the
> current position of each vehicle at regular interval (seconds).
> This transaction tab
Dear All,
I have a query in postgresql if any one can support.
A transaction table in a vehicle tracking application is inserted with the
current position of each vehicle at regular interval (seconds).
This transaction table consists of 12 columns, which are of the type varchar,
time, numeric
