i've been browsing the documentation online, and i can't
find where the storage layouts for tables and indexes are
explained.
i'd like to be able to figure out, given a table or two
with a simple schema (no ineritance) and some indexes, and
a number of rows currently in these tables, how much disk
sorry, when i referred to "disk space used" i meant the actual
amount used by live rows. if i insert 1000 rows then delete
999 of them, the disk file will be the size of the 100 row
container (make that 1000, not 100 - i cannot backspace here)
until i do a "vacuum full" - which does a table lock, w
given that someone (else) deleted the pg_xlog directory, or that it got
otherwise corrupted, is there a way to regenerate the database, given
that all the data is still safely tucked away in $PGDATA/base ???
pg
---(end of broadcast)---
TIP 3: if p
that's what i was looking for. thanks. and i see what you mean
about not really trusting that the data really is all there.
still, most is better than none.
again, thnks.
pg
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [E
size, unless i have all fixed-sized fields. in that case,
i should be able to accurately calculate the size, yes? if not, what
are the variables i could not account for?
uh, any more info on your comment "rows may be compressed or moved
to secondary storage automatically." i'
On Thu, 31 Jul 2003, Andrew Sullivan wrote:
> On Thu, Jul 31, 2003 at 08:51:09AM -0400, [EMAIL PROTECTED] wrote:
> >
> > well, i can admit that i am confused. my assumption is that when a row
> > is deleted in pg, that row is merely marked as 'gone' until a vacuum-full
> > is done. my further ass
nice stuff (the whole presentation, full of stuff i did not know), thanks.
of course, a question...
the bit that reads:
If you know the maximum value of an integer column and have an index on
it:
SELECT COUNT(*) FROM t2 WHERE c2 < 100;
made me think that the above would do an index sca
i need to get a row count on a large table. it appears that
select count(*) from ;
always does a table scan, whether i have an index or not, and that is too
slow.
so i found this:
select reltuples from pg_class where relname = '';
this is nice and fast, but not all that accurate at any given
