No, my problem is that using TSearch2 interferes with other core
components of postgres like (auto)vacuum or dump/restore.
That's nonsense...seriously.
The only trick with dump/restore is that you have to install the
tsearch2 shared library before restoring. That's the same as all
contribs
Christopher Kings-Lynne schrieb:
No, my problem is that using TSearch2 interferes with other core
components of postgres like (auto)vacuum or dump/restore.
That's nonsense...seriously.
The only trick with dump/restore is that you have to install the
tsearch2 shared library before restoring.
Edison Azzi wrote:
Hi,
I´m trying to optimize some selects between 2 tables and the best way I
found was
alter the first table and add the fields of the 2nd table. I adjusted
the contents and
now a have only one table with all info that I need. Now resides my
problem, because
of legacy
Based on a suggestion on the postgis list, I partitioned my 80 million (for
now) record table into
subtables of about 230k records (the amount of data collected in five
minutes). At the moment
I have 350 subtables.
Everything seems to be greatCOPY time is ok, building a
geometric
Stephan,
you cache is too low :) Try to increase shared_buffers, for example,
for 2Gb I'd set it to 100,000
On Wed, 7 Dec 2005, Stephan Vollmer wrote:
Hi everybody!
This is my first posting to this list and I'm quite a PostgreSQL
newbie. My question is:
The first time I execute a query, it
Hi Jan,
As I'm novice with PostgreSQL, can you elaborate the term FSM and
settings recommendations?
BTW: I'm issuing VACUUM ANALYZE every 15 minutes (using cron) and also
changes the setting of fsync to false in postgresql.conf but still time
seems to be growing.
Also no other transactions are
On Dec 6, 2005, at 5:03 PM, Ameet Kini wrote:
table with only 1 index, the time to do a vacuum (without full)
went down
from 45 minutes to under 3 minutes. Maybe thats not bloat but thats
surely surprising. And this was after running vacuum periodically.
I'll bet either your FSM settings
Thanks for your inputs, Tom. I was going after high concurrent clients,
but should have read this carefully -
-s scaling_factor
this should be used with -i (initialize) option.
number of tuples generated will be multiple of the
scaling factor. For
On Tue, 2005-12-06 at 22:49, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
1. You don't want number of clients (-c) much higher than scaling factor
(-s in the initialization step).
Should we throw a warning when someone runs the test this way?
Not a bad
Hi Oleg, thanks for your quick reply!
Oleg Bartunov wrote:
you cache is too low :) Try to increase shared_buffers, for example,
for 2Gb I'd set it to 100,000
Ok, I set shared_buffers to 10 and indeed it makes a big
difference. Other queries than the ones I mentioned are faster, too.
Edison Azzi wrote:
Richard Huxton escreveu:
However, even if you removed the condition on origem, I don't think
the planner will notice that it can eliminate the join. It's just too
unusual a case for the planner to have a rule for it.
I might be wrong about the planner - I'm just another
On Wed, Dec 07, 2005 at 14:14:31 +0200,
Assaf Yaari [EMAIL PROTECTED] wrote:
Hi Jan,
As I'm novice with PostgreSQL, can you elaborate the term FSM and
settings recommendations?
http://developer.postgresql.org/docs/postgres/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-FSM
BTW: I'm
Hi All,
I am working on an application that uses PostgreSQL. One of the
functions of the application is to generate reports. In order to keep
the code in the application simple we create a view of the required data
in the database and then simply execute a SELECT * FROM
view_of_the_data;
13 matches
Mail list logo
