> -Original Message-
> From: Gábor Farkas
>
>
> i see.
>
> will i achieve the same thing by simply dropping that table
> and re-creating it?
Yes. Or even easier (if you don't need the data anymore) you can use the
truncate command. Which deletes everything in the table including dead
On Mon, 2007-09-24 at 17:14 +0200, Gábor Farkas wrote:
> will i achieve the same thing by simply dropping that table and
> re-creating it?
If you have an index/PK on that table, the fastest and most useful way
to rebuild it is to do CLUSTER on that index. That will be a lot faster
than VACUUM FUL
In response to "Gábor Farkas" <[EMAIL PROTECTED]>:
> Heikki Linnakangas wrote:
> > Gábor Farkas wrote:
> >>
> >> if i do a full vacuum to that table only, will the database still serve
> >> data from the other tables at a normal speed?
> >
> > Yes. The extra I/O load vacuum full generates while i
Heikki Linnakangas wrote:
Gábor Farkas wrote:
if i do a full vacuum to that table only, will the database still serve
data from the other tables at a normal speed?
Yes. The extra I/O load vacuum full generates while it's running might
disrupt other activity, though.
i see.
will i achieve
Gábor Farkas wrote:
> hmm... can a full-vacuum be performed while the database is still "live"
> (i mean serving requests)?
>
> will the db still be able to respond to queries?
VACUUM FULL will exclusive lock the table, which means that other
queries accessing it will block and wait until it's fi
Heikki Linnakangas wrote:
Gábor Farkas wrote:
- but in the past, the cron-job was not in place, so the table's size
grew to around 80 entries (in around 80 days)
That bloated your table, so that there's still a lot of empty pages in
it. VACUUM FULL should bring it back to a reasonable size
Gábor Farkas wrote:
> - this table has a lot of updates and inserts, it works very similarly
> to a session-table for a web-application
Make sure you run VACUUM often enough.
> - there is a cron-job that deletes all the old entries, so it's size is
> rougly between 15000 and 35000 entries (it's r
On 9/24/07, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>
>
> INFO: "main_activity": found 41001 removable, 11672 nonremovable row
> versions in 160888 pages
> DETAIL: 0 dead row versions cannot be removed yet.
> There were 14029978 unused item pointers.
> 0 pages are entirely empty.
> CPU 5.53s/1.71
hi,
i have the following table:
CREATE TABLE "main_activity" (
"id" serial NOT NULL PRIMARY KEY,
"user_id" integer NOT NULL,
"sessionid" varchar(128) NOT NULL,
"login" timestamp with time zone NOT NULL,
"activity" timestamp with time zone NOT NULL,
"logout" timestamp with
On 8/11/07, Detlef Rudolph <[EMAIL PROTECTED]> wrote:
> Hello Group,
>
> I've tried the VACUUM ANALYSE, that doesn't help
> much, but VACUUM FULL improves Performance down
> from about 40 secs to 8.
If vacuum full fixes a performance problem, then you have a regular
vacuum problem of some sort.
M
Hello Group,
I've tried the VACUUM ANALYSE, that doesn't help
much, but VACUUM FULL improves Performance down
from about 40 secs to 8. I think in future I would
use the reltuples value from pg_class for the table.
Thanks a lot for your answers and a good Sunday,
Det
---(
>>> valgog <[EMAIL PROTECTED]> 08/13/07 6:38 AM >>>
On Aug 11, 5:54 pm, Detlef Rudolph <[EMAIL PROTECTED]> wrote:
>
> I've tried the VACUUM ANALYSE, that doesn't help
> much, but VACUUM FULL improves Performance down
> from about 40 secs to 8.
Det,
I don't think anyone meant to suggest that VA
On Aug 11, 5:54 pm, Detlef Rudolph <[EMAIL PROTECTED]> wrote:
> Hello Group,
>
> I've tried the VACUUM ANALYSE, that doesn't help
> much, but VACUUM FULL improves Performance down
> from about 40 secs to 8. I think in future I would
> use the reltuples value from pg_class for the table.
>
> Thanks
>>> On Fri, Aug 10, 2007 at 8:08 AM, in message
<[EMAIL PROTECTED]>, Brian Hurt <[EMAIL PROTECTED]>
wrote:
> runic wrote:
>
>>I have a table with ca. 1.250.000 Records. When I execute
>>a "select count (*) from table" (with pgAdmin III) it takes about 40
>>secs.
>>I think that takes much to lon
runic wrote:
Hello Group,
I'm new in PostgreSQL Business, therefore please forgive me a "newbie"
Question. I have a table with ca. 1.250.000 Records. When I execute
a "select count (*) from table" (with pgAdmin III) it takes about 40
secs.
I think that takes much to long. Can you please give m
On 8/8/07, runic <[EMAIL PROTECTED]> wrote:
> Hello Group,
>
> I'm new in PostgreSQL Business, therefore please forgive me a "newbie"
> Question. I have a table with ca. 1.250.000 Records. When I execute
> a "select count (*) from table" (with pgAdmin III) it takes about 40
> secs.
> I think that
Hello Group,
I'm new in PostgreSQL Business, therefore please forgive me a "newbie"
Question. I have a table with ca. 1.250.000 Records. When I execute
a "select count (*) from table" (with pgAdmin III) it takes about 40
secs.
I think that takes much to long. Can you please give me hints, where
I
> I'm new in PostgreSQL Business, therefore please forgive me a "newbie"
> Question. I have a table with ca. 1.250.000 Records. When I execute
> a "select count (*) from table" (with pgAdmin III) it takes about 40
> secs.
> I think that takes much to long. Can you please give me hints, where
> I c
18 matches
Mail list logo
