Stan Bielski <[EMAIL PROTECTED]> writes:
> Table "public.allflow_tv_mydoom"
>Column | Type | Modifiers
> +-+---
> tv_s | bigint |
^^
> Indexes: allflow_tv_mydoom_x btree (tv_s)
> standb=# explain select * from allflow_tv_mydoom whe
Hi,
> I have some tables (which can get pretty large) in which I want to
> record 'current' data as well as 'historical' data.
Another solution can be using a trigger and function to record every
transaction to a 'logging' table.
This way you'll have one 'current' table and one 'historical' tabl
On Fri, Aug 29, 2003 at 05:13:52PM +0200, Alexander Priem wrote:
> Well, the intention is to hold every record that ever existed in the table.
> Therefore, records do not get deleted, but they get a date in the
> deleteddate field. This way, we can track what changes were made to the
> table(s).
>
om: "Tom Lane" <[EMAIL PROTECTED]>
To: "Alexander Priem" <[EMAIL PROTECTED]>
Cc: "Tomasz Myrta" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, August 29, 2003 4:00 PM
Subject: Re: [PERFORM] Indexing question
> "Alexander Prie
"Alexander Priem" <[EMAIL PROTECTED]> writes:
> Does anyone know whether it is bad practise to have two indexes on the
> primary key of a table? (one 'primary key' index and one partial index)
It's a little unusual, but if you get enough performance boost from it
to justify the maintenance cost of
Cc: <[EMAIL PROTECTED]>
Sent: Friday, August 29, 2003 10:57 AM
Subject: Re: [PERFORM] Indexing question
> > create index orad_id_index on orderadvice (orad_id) where
orad_deleteddate
> > is null;
> > create index orad_name_index on orderadvice (orad_name) where
> > or
create index orad_id_index on orderadvice (orad_id) where orad_deleteddate
is null;
create index orad_name_index on orderadvice (orad_name) where
orad_deleteddate is null;
create view orderadvice_edit as select
orad_id,orad_name,orad_description,orad_value,orad_value_quan from
orderadvice where ora
n the table?
There would be a double index on the primary key this way, right?
Thanks for your advice so far,
Alexander Priem.
- Original Message -
From: "Tomasz Myrta" <[EMAIL PROTECTED]>
To: "Alexander Priem" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTE
> So if I understand correctly I could ditch the 'deleted' field entirely
and
> use just the 'deleteddate' field. This 'deleteddate' field would be NULL
by
> default. It would contain a date value if the record is considered
> 'deleted'.
>
> The index would be 'create index a on tablename(deletedd
So if I understand correctly I could ditch the 'deleted' field entirely and
use just the 'deleteddate' field. This 'deleteddate' field would be NULL by
default. It would contain a date value if the record is considered
'deleted'.
The index would be 'create index a on tablename(deleteddate) where
de
d of
thing, I think (theoretically at least)?
Kind regards,
Alexander Priem.
- Original Message -
From: "Tomasz Myrta" <[EMAIL PROTECTED]>
To: "Alexander Priem" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, August 29, 2003 9:03 AM
Subject: Re
Hi all,
I have some tables (which can get pretty large) in which I want to
record 'current' data as well as 'historical' data. This table has
fields 'deleted' and 'deleteddate' (among other fields, of course). The
field 'deleted' is false be default. Every record that I want to delete
gets th
Remember to consider partial indexes:
eg. CREATE INDEX ON table (col) WHERE deletedate IS NOT
NULL
Chris
- Original Message -
From:
Alexander Priem
To: [EMAIL PROTECTED]
Sent: Friday, August 29, 2003 2:52
PM
Subject: [PERFORM] Indexing
question
Hi all,
13 matches
Mail list logo
