Hi,
I'm sorry and thanks for the help, concerning your question :
"Out of interest, how are you talking to PostgreSQL? Hand-written SQL via
JDBC? Hibernate / TopLink / some other ORM (possibly via JPA)?"
I'm using JPA/Toplink to talk to the PostgresSQL, and I asked my question
about profiling bec
On 30/11/2009 4:42 PM, aymen marouani wrote:
Hi,
I'm sorry and thanks for the help, concerning your question :
"Out of interest, how are you talking to PostgreSQL? Hand-written SQL via
JDBC? Hibernate / TopLink / some other ORM (possibly via JPA)?"
I'm using JPA/Toplink to talk to the PostgresS
I have a database with a schema called ISS. This is where all of our
application definitions are stored. We did add 2 contribute modules (citext)
and guid generator and both of these by default went to the public schema.
It is our intent to not allow any access to public by our users.
A few questi
On Monday 30 November 2009 6:50:27 am Michael Gould wrote:
> I have a database with a schema called ISS. This is where all of our
> application definitions are stored. We did add 2 contribute modules
> (citext) and guid generator and both of these by default went to the public
> schema. It is our i
Thanks
Mike Gould
"Adrian Klaver" wrote:
> On Monday 30 November 2009 6:50:27 am Michael Gould wrote:
>> I have a database with a schema called ISS. This is where all of our
>> application definitions are stored. We did add 2 contribute modules
>> (citext) and guid generator and both of these by
In article <200911300708.12397.akla...@comcast.net>,
Adrian Klaver writes:
> From a quick look it would seem the easiest solution would be to change the
> search_path in:
> citext.sql.in
> uuid-ossp.sql.in
> These files are found in the respective contrib directories. Uninstall the
> modules.
On Thu, Nov 26, 2009 at 6:26 AM, aymen marouani
wrote:
>
> How can I load the auto_explain module ?
>
http://www.postgresql.org/docs/8.4/static/auto-explain.html
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387
I looking at a script that does a pg_restore followed by an immediate
VACUUM ANALYZE (postgres 8.3).
I'm told that without the VACUUM ANALYZE the database will run slow.
Does this ring true?
Does pg_restore not update the query planner statistics?
--
Sent via pgsql-sql mailing list (pgsql-sq
Bryce Nesbitt writes:
> I looking at a script that does a pg_restore followed by an immediate
> VACUUM ANALYZE (postgres 8.3).
That's standard.
> Does pg_restore not update the query planner statistics?
Correct. Autovacuum might fix them eventually, but usually it's
worth forcing the issue on
Tom Lane wrote:
Does pg_restore not update the query planner statistics?
Correct. Autovacuum might fix them eventually, but usually it's
worth forcing the issue once you've completed your data loading.
(This might involve multiple steps, which is why pg_restore
doesn't try t
Bryce Nesbitt writes:
>> Correct. Autovacuum might fix them eventually, but usually it's
>> worth forcing the issue once you've completed your data loading.
>> (This might involve multiple steps, which is why pg_restore
>> doesn't try to force it for you.)
> Hmm. It seems like pg_restore would
11 matches
Mail list logo