You were right. I just reindexed the DB and I saw no real changes in drive
storage (those tablespaces are on separate hard disk volumes). Thanks
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Reindexing-and-tablespaces-tp5789827p5789853.html
Sent from the PostgreSQL -
On Fri, Jan 31, 2014 at 1:24 PM, alexandros_e wrote:
> Hello to all,
>
> I have done ALTER DATABASE "[database_name]" SET default_tablespace =
> [new_tablespace]; I am wondering, if I reindex this entire DB would the
> indexes automatically moved into the [new_tablespace] or will they remain in
>
Hello to all,
I have done ALTER DATABASE "[database_name]" SET default_tablespace =
[new_tablespace]; I am wondering, if I reindex this entire DB would the
indexes automatically moved into the [new_tablespace] or will they remain in
the tablespace they were originally created on;
--
View this
On Mon, Feb 7, 2011 at 17:28, akp geek wrote:
> thanks.. the index I was having is gist on a to_tsvector column . version we
> have is 8.3
What minor version? I sounds like you _could_ be hitting any of the below:
- (8.3.14) Fix detection of page splits in temporary GiST indexes
(Heikki Linnakang
thanks.. the index I was having is gist on a to_tsvector column . version we
have is 8.3
On Mon, Feb 7, 2011 at 7:23 PM, Alex Hunsaker wrote:
> On Mon, Feb 7, 2011 at 17:12, akp geek wrote:
> > Hi all -
> > I ran query this morning, I got a wrong results. I have run the
> same
> > query
On Mon, Feb 7, 2011 at 17:12, akp geek wrote:
> Hi all -
> I ran query this morning, I got a wrong results. I have run the same
> query in an other environment with same data and I got the result set I was
> expecting.
> After that I did a re index and on the table I was getting inc
Hi all -
I ran query this morning, I got a wrong results. I have run the same
query in an other environment with same data and I got the result set I was
expecting.
After that I did a re index and on the table I was getting incorrect
results, the data then came out fine,
D
Greg Smith wrote:
If some big-iron shop who is so blind to security issues that they want
to keep 7.4 on life support, they certainly can find someone to deliver
such a support agreement on a contract basis. But they shouldn't expect
the public project to keep them afloat for free, and saying
Greg Smith <[EMAIL PROTECTED]> writes:
> If some big-iron shop who is so blind to security issues that they want to
> keep 7.4 on life support, they certainly can find someone to deliver such
> a support agreement on a contract basis. But they shouldn't expect the
> public project to keep them
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 27 Feb 2008 11:28:32 -0500
Lew <[EMAIL PROTECTED]> wrote:
> In my experience at various "big-iron" shops (government agencies,
> large health-care organizations and the like), four years is not a
> long time for enterprise software - a version
On Wed, 27 Feb 2008, Lew wrote:
One has only to look at how many organizations still use Oracle 8, or
Java 1.3, for example, to see how conservative many shops are with
respect to upgrades. I'm not saying they should be that conservative,
but many organizations are and we must be ready to dea
Lew <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There never was a 7.1.4 release, so I suspect the OP meant 7.4.1
>> not that that speaks very much better for his software maintenance
>> habits. Even with the more charitable interpretation, it's a version
>> that was obsoleted four years
Lew wrote:
Tom Lane wrote:
There never was a 7.1.4 release, so I suspect the OP meant 7.4.1
not that that speaks very much better for his software maintenance
habits. Even with the more charitable interpretation, it's a version
that was obsoleted four years ago next week.
In my experienc
Tom Lane wrote:
There never was a 7.1.4 release, so I suspect the OP meant 7.4.1
not that that speaks very much better for his software maintenance
habits. Even with the more charitable interpretation, it's a version
that was obsoleted four years ago next week.
In my experience at various
"Scott Marlowe" <[EMAIL PROTECTED]> writes:
> On Fri, Feb 22, 2008 at 12:24 PM, LARC/J.L.Shipman/jshipman
> <[EMAIL PROTECTED]> wrote:
>> I am reindexing my 7.1.4 postgres database.
> My pgsql-fu regarding obsolete versions is obsolete. You do realize
> that 7.1.x hasn't been supported for a very
On Fri, Feb 22, 2008 at 12:24 PM, LARC/J.L.Shipman/jshipman
<[EMAIL PROTECTED]> wrote:
> Hi,
> I am reindexing my 7.1.4 postgres database. The postmaster seems to
> create processes for each reindex request. Is there any way to find
> out more about the processes.
>
> ps -aef | grep po
Hi,
I am reindexing my 7.1.4 postgres database. The postmaster seems to
create processes for each reindex request. Is there any way to find
out more about the processes.
ps -aef | grep postgres
yields the following, but does not tell me which table is being
reindexed or anything meanin
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Thu, Aug 02, 2007 at 10:40:24PM -0400, Joseph S wrote:
>> I do use autovac. Like I said they don't get really out of hand, only
>> up to 20 megs or so before I noticed that it was weird. The large
>> indexes are what tipped me off that something str
On Thu, Aug 02, 2007 at 10:40:24PM -0400, Joseph S wrote:
> Tom Lane wrote:
> >Heavy use of temp tables would expand pg_class, pg_type, and especially
> >pg_attribute, but as long as you have a decent vacuuming regimen (do you
> >use autovac?) they shouldn't get out of hand.
>
> I do use autovac.
Joseph S <[EMAIL PROTECTED]> writes:
> ... and when I notice that the tuplesperpage for the indexes is low (or
> that the indexes are bigger then the tables themselves) I know it is
> time for a VACUUM FULL and REINDEX on that table.
If you are taking the latter as a blind must-be-wrong conditio
Tom Lane wrote:
Joseph S <[EMAIL PROTECTED]> writes:
Me too. I don't change my db schema that much, but I experience bloat
in the pg_tables that I don't expect. For instance pg_opclass needs a
VACUUM FULL/REINDEX once a week or I notice the indexes are larger than
the table itself. Could it
Me too. I don't change my db schema that much, but I experience bloat
in the pg_tables that I don't expect. For instance pg_opclass needs a
VACUUM FULL/REINDEX once a week or I notice the indexes are larger than
the table itself. Could it be my heavy use of temp tables?
Today I noticed that
Joseph S <[EMAIL PROTECTED]> writes:
> Me too. I don't change my db schema that much, but I experience bloat
> in the pg_tables that I don't expect. For instance pg_opclass needs a
> VACUUM FULL/REINDEX once a week or I notice the indexes are larger than
> the table itself. Could it be my hea
Joseph S <[EMAIL PROTECTED]> writes:
> My pg_shdepend table has a size of 16,384, but
> pg_shdepend_depender_index has a size of 19,169,280 and
> pg_shdepend_reference_index has a size of 49,152.
I'd be interested to see the usage pattern that made it get like that
...
r
Joseph S wrote:
> My pg_shdepend table has a size of 16,384, but pg_shdepend_depender_index
> has a size of 19,169,280 and pg_shdepend_reference_index has a size of
> 49,152. When I try to reindex the table I get:
>
> ERROR: shared table "pg_shdepend" can only be reindexed in stand-alone
> mod
My pg_shdepend table has a size of 16,384, but
pg_shdepend_depender_index has a size of 19,169,280 and
pg_shdepend_reference_index has a size of 49,152. When I try to reindex
the table I get:
ERROR: shared table "pg_shdepend" can only be reindexed in stand-alone mode
So is there any way I c
In response to "Harpreet Dhaliwal" <[EMAIL PROTECTED]>:
> Hi,
> Lately i was searching for a way I could reindex all my keys. Primary Keys
> in particular.
> Really didn't find any manual that could guide me through.
>
> Reason i wanted to reindex my PK is that whenever i insert a record in the
>
Hi,
Lately i was searching for a way I could reindex all my keys. Primary Keys
in particular.
Really didn't find any manual that could guide me through.
Reason i wanted to reindex my PK is that whenever i insert a record in the
table, even though that record is unique, i get an error saying viola
"mike" wrote:
>is there a way to reindex a sequence?
>if so how and is it in the curent docs?
If you wish to reset its value, the function is setval().
--
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight http://www.lfix.co.uk/oliver
From: "mike" <[EMAIL PROTECTED]>
is there a way to reindex a sequence?
if so how and is it in the curent docs?
Mike
Reindex a sequence? Not sure what you mean by that. You can set the value to
something else:
select setval('mysequence',12345);
If you mean compact the values used so there are
"mike" <[EMAIL PROTECTED]> writes:
> is there a way to reindex a sequence?
Sequences don't have indexes, so they don't need reindexing.
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, pl
is there a way to reindex a sequence?
if so how and is it in the curent
docs?
Mike
32 matches
Mail list logo
