On Sat, Feb 12, 2005 at 01:16:49AM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > Is VACUUM in 8.x supposed to be overestimating reltuples by 50% of
> > the number of dead tuples?
>
> See this thread:
> http://archives.postgresql.org/pgsql-hackers/2004-11/msg01043.php
Thank
Michael Fuhr <[EMAIL PROTECTED]> writes:
> Is VACUUM in 8.x supposed to be overestimating reltuples by 50% of
> the number of dead tuples?
See this thread:
http://archives.postgresql.org/pgsql-hackers/2004-11/msg01043.php
regards, tom lane
---(end
Is VACUUM in 8.x supposed to be overestimating reltuples by 50% of
the number of dead tuples?
CREATE TABLE foo (x integer);
INSERT INTO foo SELECT * FROM generate_series(1, 1000);
UPDATE foo SET x = x;
UPDATE foo SET x = x;
UPDATE foo SET x = x;
VACUUM foo;
SELECT relpages, reltuples FROM pg_class
Bruce Momjian writes:
> Tom Lane wrote:
>> It's certainly not realistic to pass back enough information from
>> rmtree() to let the caller print a useful error message, so I think
>> we have to add reporting code along this line to rmtree().
> Agreed. Not sure how the rmtree stuff was removed.
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> [ looks at code... ] dbcommands.c is expecting that rmtree() will have
> >> printed out a more-detailed message about the problem, but someone has
> >> carefully removed every trace of error reporting from rmtree().
>
> > I think t
Bruce Momjian writes:
> Tom Lane wrote:
>> [ looks at code... ] dbcommands.c is expecting that rmtree() will have
>> printed out a more-detailed message about the problem, but someone has
>> carefully removed every trace of error reporting from rmtree().
> I think the issue is that we didn't wan
Tom Lane wrote:
> =?ISO-8859-15?Q?Hubert_Fr=F6hlich?= <[EMAIL PROTECTED]> writes:
> > dropdb ax20050206
> > WARNING: could not remove database directory
> > "/export/home/postgres/data2/base/115101837"
> > DROP DATABASE
>
> That's not very helpful, is it?
>
> [ looks at code... ] dbcommands.c
=?ISO-8859-15?Q?Hubert_Fr=F6hlich?= <[EMAIL PROTECTED]> writes:
> dropdb ax20050206
> WARNING: could not remove database directory
> "/export/home/postgres/data2/base/115101837"
> DROP DATABASE
That's not very helpful, is it?
[ looks at code... ] dbcommands.c is expecting that rmtree() will ha
Sibtay Abbas <[EMAIL PROTECTED]> writes:
> One of my tasks includes allowing plpgsql functions to pass parameters by
> reference.
What do you envision the context of this to be? You certainly can't
suppose that it's sane for
SELECT foo(col) FROM tab;
to modify the table column.
I was asked to give a lectures (a whole day) about PostgreSQL in Moscow, Russia.
Since I'm new to such kind of activity I'n looking for any presentations,
curlliculum for starting.
Regards,
Oleg
_
Oleg Bartunov, sci
> I asked the question how do you get a record without going through an
> index, the answer was CTID, which unfortunately changes when the row is
> updated.
The ctid is a physical location of the row. On update a new tuple is written
in a new location, that is why the ctid changes. The old tuple
hello all
as i have mentioned this before, as part of my academic project
i am required to make modifications in postgresql.
One of my tasks includes allowing plpgsql functions to pass parameters by
reference. For this purpose I have been digging in the code for plpgsql
and postgresql for 2 days
12 matches
Mail list logo
