Re: splitting a table? - Mailing list pgsql-general

From Johnson, Shaunn
Subject Re: splitting a table?
Date
Msg-id 73309C2FDD95D11192E60008C7B1D5BB05FED480@snt452.corp.bcbsm.com
Whole thread Raw
In response to splitting a table?  ("Johnson, Shaunn" <SJohnson6@bcbsm.com>)
List pgsql-general

--howdy:

--let me be sure i understand this:

--how can i calculate to see if i have enough
--memory allocated for the shared buffers?
--for example, we have a gig of ram ... what
--should the ratio look like.

--the indexes i have for the table looks like
--this:

[snip index]
test_db=> \d ref_dcg_pkey

   Index "ref_dcg_pkey"
  Column  |     Type
----------+---------------
 contract | character(12)
 mbr_num  | character(2)
 id       | smallint
unique btree (primary key)

[/snip index]

--are you saying that i should create
--a seperate one as well for each column
--that i may query against (say, i search
--for contract more often than the combo
--i have above)?

-----Original Message-----
From: Arjen van der Meijden [mailto:acm@tweakers.net]

[snip some stuff]

> Things to check for:
>  - Have you run VACCUM FULL or VACUUM ANALYSE recently?
>  - Are your "where" data-types the same as the index data-types?
>  - See if the indexes are used in the EXPLAIN ANALYSE output.

And of course whether the hd-parameters are set in case of an ide disk,
whether there is sufficient memory allocated for the shared buffers,
etc.

It may also be wise to have multiple indexes. If you, for instance,
search very often on a combination of values and very often on a single
value two indexes (the combined one and the separate one) could improve
both queries. Although the combined index would be used in both cases if
that were the only index, it isn't the most efficient index to use in
that case, afaik.

Arjen

pgsql-general by date:

Previous
From: "Johnson, Shaunn"
Date:
Subject: Re: splitting a table?
Next
From: Nailah Ogeer
Date:
Subject: Re: [HACKERS] psql