On Thu, Apr 17, 2008 at 9:42 AM, Gunther Mayer
<[EMAIL PROTECTED]> wrote:
> Pavan Deolasee wrote:
>
> > 2. The existing block should have enough free space to accommodate the
> > new version
> > A less than 100 fillfactor may help you given your rate of updates.
> >
> >
> I see, as soon as a new
Pavan Deolasee wrote:
On Thu, Apr 17, 2008 at 2:57 PM, Gunther Mayer
<[EMAIL PROTECTED]> wrote:
You see, all updates change most of the data fields but never ever touch
the time field. Assuming correct and efficient behaviour of postgresql it
should then also never touch the time index and i
On Thu, Apr 17, 2008 at 2:57 PM, Gunther Mayer
<[EMAIL PROTECTED]> wrote:
>
>
> You see, all updates change most of the data fields but never ever touch
> the time field. Assuming correct and efficient behaviour of postgresql it
> should then also never touch the time index and incur zero overhead
Gunther Mayer wrote:
You see, all updates change most of the data fields but never ever touch
the time field. Assuming correct and efficient behaviour of postgresql
it should then also never touch the time index and incur zero overhead
in its presence, but is this really the case? If it somehow
Gunther Mayer wrote:
You see, all updates change most of the data fields but never ever touch
the time field. Assuming correct and efficient behaviour of postgresql
it should then also never touch the time index and incur zero overhead
in its presence, but is this really the case? If it somehow
Hi there,
I have a table which looks similar to:
CREATE TABLE accounting
(
id text NOT NULL,
time timestamp with time zone,
data1 int,
data2 int,
data3 int,
data4 int,
data5 int,
data6 int,
data7 int,
data8 int,
state int
CONSTRAINT accounting_pkey PRIMARY KEY (id),
)
The table has
