> I've encountered this before, psql gives me a syntax error for no clear
> reason. It's allways on the first character of a sql file.
> I think that there must be some strange character code at the first
> position, maybe it is because i share a ntfs partition with the windows
> installation on m
Hi,
I've encountered this before, psql gives me a syntax error for no clear
reason. It's allways on the first character of a sql file.
I think that there must be some strange character code at the first
position, maybe it is because i share a ntfs partition with the windows
installation on my lapt
Le 03/12/2010 16:19, Little, Douglas a écrit :
>
>
> Sorry, outlook must of clobbered the table.
>
> [cid:image001.png@01CB92CB.11EA5F60]
>
>
>
> Pg_attribute has 513871 tuples and should take up 2135 pages. It's
> currently allocated to 98646 pages.
>
> Given that much bloat, what woul
Le 03/12/2010 16:28, Little, Douglas a écrit :
> Somehow this moved to the pgadmin list. It was intended for pgsql-admin. My
> apologies.
> This is a dba task, I'd never expect pgadmin would do this.
>
It didn't *move* to the pgadmin list, your first mail was sent there.
pgAdmin doesn't do it
Le 03/12/2010 16:24, Little, Douglas a écrit :
> Michael,
>
> I hear that vacuum full shouldn't be used.
> But what impact does the bloat have on performance?
Bigger on your hard, so slower to scan. And bigger in memory, so you
need to push blocks out to scan it. Other than that, not much.
It's
Le 03/12/2010 16:25, Michael Shapiro a écrit :
> I understand, but in this case, since the option is offered next to the safe
> one, most people won't know it isn't safe.
Both are safe. They don't offer the same service. VACUUM will allow
PostgreSQL to reuse dead space, VACUUM FULL will free space
Somehow this moved to the pgadmin list. It was intended for pgsql-admin. My
apologies.
This is a dba task, I'd never expect pgadmin would do this.
From: Michael Shapiro [mailto:mshapir...@gmail.com]
Sent: Friday, December 03, 2010 9:26 AM
To: Guillaume Lelarge
Cc: Little, Douglas; PgAdmin Sup
I understand, but in this case, since the option is offered next to the safe
one, most people won't know it isn't safe.
I certainly didn't until I read this posting. I know generally what
vacuuming does, but I had no idea that postgres offered a potentially
damaging option. Also, PgAdmin sometimes
Le 03/12/2010 15:17, Michael Shapiro a écrit :
> The document http://wiki.postgresql.org/wiki/VACUUM_FULL says:
>
> VACUUM FULL, unlike VACUUM, tuples data that has not been deleted, moving it
> into spaces earlier in the file that have been freed. Once it's created a
> free space at the end of th
The document http://wiki.postgresql.org/wiki/VACUUM_FULL says:
VACUUM FULL, unlike VACUUM, tuples data that has not been deleted, moving it
into spaces earlier in the file that have been freed. Once it's created a
free space at the end of the file, it truncates the file so that the OS
knows that s
Le 03/12/2010 14:40, Little, Douglas a écrit :
> [...]
> Given this syscat bloat, what would you recommend doing?
>
Sorry but that's really unreadable.
--
Guillaume
http://www.postgresql.fr
http://dalibo.com
--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make
Guillaume,
Given this syscat bloat, what would you recommend doing?
schemaname
tablename
reltuples
relpages
otta
tbloat
wastedpages
wastedbytes
wastedsize
pg_catalog
pg_exttable
7092
3137
49
64
3088
101187584
97 MB
pg_catalog
pg_shdepend
48674
2349
84
28
2265
74219520
Hi,
Le 03/12/2010 00:19, Little, Douglas a écrit :
> [...]
> Thanks for the response.
No problem, but keep your anwser to the list, even if it's not the good
one :)
> Still a bit confused.
> Q: The guk settings max_fsm_relations/pages are used by the db engine to set
> the size of the freespac
13 matches
Mail list logo
