Excerpts from Greg Smith's message of lun jun 07 12:23:44 -0400 2010:
> It is a periodic preventative maintenance operation you can expect to
> need occasionally, but certainly not often. Indexes maintain themselves
> just fine most of the time. They can get out of whack if you delete a
> lot
gareth.willi...@csiro.au wrote:
Re-reading the documentation
http://www.postgresql.org/docs/8.4/interactive/sql-reindex.html it is clear now
that reindex or recreating and index should not normally be needed - certainly
not to keep an index up-to-date. I would have guessed that VACUUM or VACU
> Thanks Greg, Alban and others,
>
> This has cleared up a misunderstanding I had about why one should reindex.
> Re-reading the documentation
> http://www.postgresql.org/docs/8.4/interactive/sql-reindex.html it is clear
> now that reindex or recreating and index should not normally be needed
> -Original Message-
> From: Greg Smith [mailto:g...@2ndquadrant.com]
-snip-
>
> Gareth.Williams wrote:
> > So the rest of the question is, if I have two indexes with identical
> definitions, what happens? I've confirmed that I can create indexes with
> identical definitions (except name)
Excerpts from Gareth.Williams's message of mar jun 01 02:44:35 -0400 2010:
> Hi,
>
> We want to reindex the database behind a production service without
> interrupting the service.
>
> I had an idea for creating the index with a new name then dropping the
> existing index and renaming the new o
gareth.willi...@csiro.au wrote:
I'm concerned that just because I *can* create duplicate indexes, it doesn't
mean I *should*. I'm worried it might actually break the service worse than
the locking that I'm trying to avoid. Does anyone know which index will be used
if there are duplicate ones
On Tue, Jun 1, 2010 at 10:00 PM, wrote:
> I'm concerned that just because I *can* create duplicate indexes, it doesn't
> mean I *should*.
> I'm worried it might actually break the service worse than the locking that
>I'm trying to avoid.
> Does anyone know which index will be used if there are
On 2 Jun 2010, at 6:00,
wrote:
> My understanding was that the index would not be updated for inserts to the
> actual table - which is why one has to reindex or drop the index and create
> it again (with concurrently if you don't want to block reads). Am I missing
> something?
That's defini
> When you have two exactly the same index definitions, that's just a
> waste of resources. There will be used only one of them for speeding up
> selects, but all of them must be updated during insert/update/delete
> operations.
Thanks Szymon,
I appreciate the info. The duplication wou
gareth.willi...@csiro.au wrote:
So the rest of the question is, if I have two indexes with identical
definitions, what happens? I've confirmed that I can create indexes with
identical definitions (except name) without postgres complaining - and without
breaking the client on my test system -
> From: Szymon Guz [mailto:mabew...@gmail.com]
-snip-
>> 2010/6/1
>> Hi,
>> We want to reindex the database behind a production service without
>> interrupting the service.
>> I had an idea for creating the index with a new name then dropping the
>> existing index and renaming the new one - a
2010/6/1
> > From: Szymon Guz [mailto:mabew...@gmail.com]
> -snip-
> >> 2010/6/1
> >> Hi,
>
> >> We want to reindex the database behind a production service without
> interrupting the service.
>
> >> I had an idea for creating the index with a new name then dropping the
> existing index and rena
2010/6/1
> Hi,
>
> We want to reindex the database behind a production service without
> interrupting the service.
>
> I had an idea for creating the index with a new name then dropping the
> existing index and renaming the new one - and it seems to work and would
> reduce the time without an ind
Hi,
We want to reindex the database behind a production service without
interrupting the service.
I had an idea for creating the index with a new name then dropping the existing
index and renaming the new one - and it seems to work and would reduce the time
without an index to be minimal. I t
14 matches
Mail list logo