That file will be regenerated from SGML before release --- the SGML
version is fixed.
---
Gaetano Mendola wrote:
> Hi,
> the INSTALL file say:
>
>* Flex and Bison are needed to build a CVS checkout or if you changed
Hi,
the INSTALL file say:
* Flex and Bison are needed to build a CVS checkout or if you changed the
actual scanner and parser definition files. If you need them, be
sure to
get Flex 2.5.4 or later and Bison 1.50 or later. Other yacc
programs can
sometimes be used, but doing
Tomas Szepe <[EMAIL PROTECTED]> writes:
> indexes:
> stats_min_pkey primary key btree (ip, "start")
> stats_min_start btree ("start")
> stats_hr_pkey primary key btree (ip, "start")
> stats_hr_start btree ("start")
> ip is of type "inet" in all tables.
> start is of type "timestamp without time zo
Tomas Szepe wrote:
INFO: --Relation public.stats_min--
INFO: Index stats_min_start: Pages 34445; Tuples 1985464: Deleted 404651.
CPU 1.19s/2.41u sec elapsed 17.86 sec.
INFO: Index stats_min_pkey: Pages 76501; Tuples 1986938: Deleted 404651.
CPU 3.98s/5.47u sec elapsed 217.07 sec.
> [EMAIL PROTECTED]
>
> You've definitely got an index-bloat problem on stats_min (the indexes
> are four times the size of the table :-(), and I suspect the same on
> stats_hr, though not quite as bad. What are the datatypes of the
> index columns?
indexes:
stats_min_pkey primary key btree (ip,
Tomas Szepe <[EMAIL PROTECTED]> writes:
> INFO: --Relation public.stats_min--
> INFO: Index stats_min_start: Pages 34445; Tuples 1985464: Deleted 404651.
> CPU 1.19s/2.41u sec elapsed 17.86 sec.
> INFO: Index stats_min_pkey: Pages 76501; Tuples 1986938: Deleted 404651.
> CPU 3.98s/5.
> > The output of VACUUM VERBOSE for the problem table(s) would be
> > interesting.
>
> Just posted, please see my message to
> Stephan Szabo <[EMAIL PROTECTED]>, CC [EMAIL PROTECTED]
> with Message-ID: <[EMAIL PROTECTED]>
Oh, and the names of the problematic tables are stats_min and stats_hr.
-
> [EMAIL PROTECTED]
>
> Tomas Szepe <[EMAIL PROTECTED]> writes:
> > I'm afraid so. The weird thing is, we once tried running
> > VACUUM FULL followed by REINDEX and although the process
> > took ages to complete, it didn't seem to help either. :(
>
> > I'll post whatever debug data I'm asked for
Tomas Szepe <[EMAIL PROTECTED]> writes:
> I'm afraid so. The weird thing is, we once tried running
> VACUUM FULL followed by REINDEX and although the process
> took ages to complete, it didn't seem to help either. :(
> I'll post whatever debug data I'm asked for, just don't make
> me run VACUUM F
> [EMAIL PROTECTED]
>
> Tomas Szepe <[EMAIL PROTECTED]> writes:
> > We have a production database that happens to receive several
> > thousand row updates per minute. We VACUUM ANALYZE every four
> > hours with max_fsm_pages set to 210, and it's no use.
>
> Have you spent any time determinin
> [EMAIL PROTECTED]
>
> On Fri, 26 Sep 2003, Tomas Szepe wrote:
>
> > > [EMAIL PROTECTED]
> > >
> > > Did you use -f on the vacuumdb? If not, it did a normal vacuum (which
> > > isn't likely to help) not a full vacuum.
> >
> > There are scenarios where VACUUM FULL is not an option because
> > of
Tomas Szepe <[EMAIL PROTECTED]> writes:
> We have a production database that happens to receive several
> thousand row updates per minute. We VACUUM ANALYZE every four
> hours with max_fsm_pages set to 210, and it's no use.
Have you spent any time determining exactly where the problem is?
I'm
On Fri, 26 Sep 2003, Tomas Szepe wrote:
> > [EMAIL PROTECTED]
> >
> > Did you use -f on the vacuumdb? If not, it did a normal vacuum (which
> > isn't likely to help) not a full vacuum.
>
> There are scenarios where VACUUM FULL is not an option because
> of its resource-hungriness and plain VACUU
> [EMAIL PROTECTED]
>
> Did you use -f on the vacuumdb? If not, it did a normal vacuum (which
> isn't likely to help) not a full vacuum.
There are scenarios where VACUUM FULL is not an option because
of its resource-hungriness and plain VACUUM just doesn't seem
to help.
We have a production dat
This has been fixed in the current CVS snapshot and will be in the next
7.4 beta. Thanks.
---
Ben Grimm wrote:
> I haven't tried the 7.4 beta, so it may be fixed there - but in
> 7.3.4, pg_dumpall doesn't generate the comma
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > This has been added to the 7.4 open items list:
> > ftp://momjian.postgresql.org/pub/postgresql/open_items
>
> That was fixed some time ago.
OK. Was it this commit? I assume so.
--
Bruce Momjian| ht
Bruce Momjian <[EMAIL PROTECTED]> writes:
> This has been added to the 7.4 open items list:
> ftp://momjian.postgresql.org/pub/postgresql/open_items
That was fixed some time ago.
regards, tom lane
> ---
This has been added to the 7.4 open items list:
ftp://momjian.postgresql.org/pub/postgresql/open_items
---
Joseph Shraibman wrote:
> The output of the vacuum command on
> http://developer.postgresql.org/docs/postgr
I ran into the following problem building PostgreSQL 7.4beta3 on
Solaris9 (sparc) using GCC 3.3 and OpenSSL 0.9.7b and Perl 5.8.0:
(./configure --with-perl --with-openssl)
gcc -shared -h libplpgsql.so.1 pl_gram.o
pl_handler.o pl_comp.o pl_exec.o pl_funcs.o -L../../../../src/port
-L/usr/local/
Quoting Stephan Szabo <[EMAIL PROTECTED]>:
> On Thu, 25 Sep 2003, Javier Carlos wrote:
>
> >
>
> > POSTGRESQL BUG REPORT TEMPLATE
> >
>
Quoting Stephan Szabo <[EMAIL PROTECTED]>:
> On Thu, 25 Sep 2003, Javier Carlos wrote:
>
> > Quoting Stephan Szabo <[EMAIL PROTECTED]>:
> >
> > > On Thu, 25 Sep 2003, Javier Carlos wrote:
> > >
> > > >
> > >
>
> > > >
[EMAIL PROTECTED] (Javier Carlos) writes:
> *** When I make a 'DROP DATABASE' to the database where that table belongs to,
> mi /var partition returns to its original size (in this example to 9%).
VACUUM ANALYZE is your friend, here.
PostgreSQL uses MVCC, wherein each update results in the creat
Hi,
I downloaded the source code for version 7.4 Beta 3, and tried to compile
with Visual C++ 6.0, using the following command from a DOS window:
nmake /f win32.mak
when the make runs, at some point during the compilation, it stops and
reports the following error:
pthread.h cannot be found.
I
23 matches
Mail list logo
