Tom Lane wrote:
> Ryan Bradetich <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Ryan Bradetich <[EMAIL PROTECTED]> writes:
> >>>> -- dumping out the contents of Table 'medusa'
> >>>> FATAL 1: Memory exhausted in Allo
Tom Lane wrote:
> Ryan Bradetich <[EMAIL PROTECTED]> writes:
> > -- dumping out the contents of Table 'medusa'
> > FATAL 1: Memory exhausted in AllocSetAlloc()
> > PQendcopy: resetting connection
> > SQL query to dump the contents of Table 'medus
Hello all,
I am having a new problem with pg_dumpall that I have not seen before.
I've been
browsing the documentation and could not find anything related to this
problem. Any
ideas or pointers would greatly be appreciated.
boi260 sanity $ /opt/pgsql/bin/pg_dumpall -v -o | /usr/contrib/bin/gzip
Tom Lane wrote:
> Ryan Bradetich <[EMAIL PROTECTED]> writes:
> > This worked great! Is their a place I can change the default to 3?
> > I do not want to change all the scripts to include this :)
>
> See src/include/optimizer/cost.h. However, I am currently thinking o
Tom Lane wrote:
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> >> One way to put a thumb on the scales is to reduce the value of the SET
> >> variable random_page_cost. The default value is 4.0, which seems to
> >> correspond more or less to reality, but reducing it to 3 or so would
> >> shift
Tom Lane wrote:
> Ryan Bradetich <[EMAIL PROTECTED]> writes:
> > I am in the process of transitioning from postgreSQL 6.5.3 to
> > postgreSQL 7.0. I ran into an issue where a sequential scan
> > is being choosen on postgreSQL 7.0 where an index scan was
>
Tom (Or anyone else who is good with PostgreSQL statistics),
I am in the process of transitioning from postgreSQL 6.5.3 to
postgreSQL 7.0. I ran into an issue where a sequential scan
is being choosen on postgreSQL 7.0 where an index scan was
choosen on postgreSQL 6.5.3.
Note: All tables have be
