"D'Arcy J.M. Cain" <[EMAIL PROTECTED]> writes:
> In any case, if I have to vacuum a 20,000,000 row table to get an accurate
> count then I may as well run count(*) on it.
> (*): Actually I only analyze but I understand that that should be sufficient.
ANALYZE without VACUUM will deliver a not-very
Josh Berkus <[EMAIL PROTECTED]> writes:
> Incidentally, just ANALYZE would probably have fixed your problem.
... or just VACUUM; that would have updated the row count which is all
that was really needed here. The main point is that you do have to do
that as superuser, since the same commands issu
On January 6, 2004 07:20 am, Shridhar Daithankar wrote:
> On Tuesday 06 January 2004 17:48, D'Arcy J.M. Cain wrote:
> > On January 6, 2004 01:42 am, Shridhar Daithankar wrote:
> > cert=# select relpages,reltuples::bigint from pg_class where relname=
> > 'certificate';
> > relpages | reltuples
> >
Mark,
> That seemed to fix it. What does VACUUM ANALYZE do that VACUUM FULL does
> not? What causes a database to need vacuuming?
See the Online Docs:
http://www.postgresql.org/docs/current/static/maintenance.html
Incidentally, just ANALYZE would probably have fixed your problem. Please do
s
That seemed to fix it. What does VACUUM ANALYZE do that VACUUM FULL does
not? What causes a database to need vacuuming?
At 01:01 PM 1/6/2004 -0800, Josh Berkus wrote:
Michael,
> With a particular database, PgAdmin3 takes a very long time to connect
to a
> database. this is not a general probl
Michael,
> With a particular database, PgAdmin3 takes a very long time to connect to a
> database. this is not a general problem with PgAdmin, but only with one
> database out of many. Other databases do not have the problem. And only
> with one particular server. The exact same database on a d
I have reported this on the pgadmin-support mailing list, but Andreas Pflug
has asked me to post it here.
With a particular database, PgAdmin3 takes a very long time to connect to a
database. this is not a general problem with PgAdmin, but only with one
database out of many. Other databases do
if this situation persists after 'analyze certificate', then you need to:
increase the statistics target 'alter table certificate alter column
certificate_id set statistics 100'
or
'vacuum full certificate'
i.e : there are lots of (dead) updated or deleted tuples in the
relation, distributed
Greg Stark <[EMAIL PROTECTED]> writes:
> Clive Page <[EMAIL PROTECTED]> writes:
>> It would be nice if OFFSET could be implemented in some more efficient
>> way.
> You could do something like:
> select myfunc(mycol) from (select mycol from table limit 50 offset 1) as x;
Note that this won't
Clive Page <[EMAIL PROTECTED]> writes:
> SELECT myfunc(mycol) FROM table LIMIT 50 OFFSET 1 ;
> It looks as if OFFSET is implemented just be throwing away the results,
> until the OFFSET has been reached.
>
> It would be nice if OFFSET could be implemented in some more efficient
> way.
You
Robert Treat wrote:
On Tue, 2004-01-06 at 07:20, Shridhar Daithankar wrote:
The numbers from pg_class are estimates updated by vacuum /analyze. Of course
you need to run vacuum frequent enough for that statistics to be updated all
the time or run autovacuum daemon..
Ran into same problem on my m
On Tue, 2004-01-06 at 07:20, Shridhar Daithankar wrote:
> On Tuesday 06 January 2004 17:48, D'Arcy J.M. Cain wrote:
> > On January 6, 2004 01:42 am, Shridhar Daithankar wrote:
> > cert=# select relpages,reltuples::bigint from pg_class where relname=
> > 'certificate';
> > relpages | reltuples
> >
I have just discovered that if one does a SELECT with a LIMIT and OFFSET
values, say
SELECT myfunc(mycol) FROM table LIMIT 50 OFFSET 1 ;
Then the whole of the selection expressions, including the function calls,
are actuall executed for every record, not just those being selected but
als
On Tuesday 06 January 2004 17:48, D'Arcy J.M. Cain wrote:
> On January 6, 2004 01:42 am, Shridhar Daithankar wrote:
> cert=# select relpages,reltuples::bigint from pg_class where relname=
> 'certificate';
> relpages | reltuples
> --+---
>399070 | 24858736
> (1 row)
>
> But:
>
On January 6, 2004 01:42 am, Shridhar Daithankar wrote:
> On Tuesday 06 January 2004 01:22, Rod Taylor wrote:
> > Anyway, with Rules you can force this:
> >
> > ON INSERT UPDATE counter SET tablecount = tablecount + 1;
> >
> > ON DELETE UPDATE counter SET tablecount = tablecount - 1;
>
> That would
15 matches
Mail list logo
