I just installed v7.4 and restored a database from v7.3.4. I have an
index based on a function that the planner is using on the old version,
but doing seq scans on left joins in the new version. I have run
analyze on the table post restore. the query returns in less than 1
second on version
William Yu [EMAIL PROTECTED] writes:
I then tried to put the WAL directory onto a ramdisk. I turned off
swapping, created a tmpfs mount point and copied the pg_xlog directory
over. Everything looked fine as far as I could tell but Postgres just
panic'd with a file permissions error. Anybody
On Wednesday 26 November 2003 16:38, Roger Ging wrote:
I just installed v7.4 and restored a database from v7.3.4.
[snip]
Hmm - you seem to be getting different row estimates in the plan. Can you
re-analyse both versions and post EXPLAIN ANALYSE rather than just EXPLAIN?
- Seq
Tom Lane wrote:
William Yu [EMAIL PROTECTED] writes:
I then tried to put the WAL directory onto a ramdisk. I turned off
swapping, created a tmpfs mount point and copied the pg_xlog directory
over. Everything looked fine as far as I could tell but Postgres just
panic'd with a file permissions
But the permissions of the base ramdisk might be wrong. I'd su to the
user that you run postgres as (probably postgres), and make sure that
you can go to the directory where the log and the database files are and
make sure you can see the files.
On Wed, Nov 26, 2003 at 10:03:47AM -0800, William
On Wednesday 26 November 2003 18:39, Roger Ging wrote:
version 7.4 results:
explain analyse SELECT L.row_id FROM music.logfile L LEFT JOIN
music.program P ON
music.fn_mri_id_no_program(P.mri_id_no) = L.program_id
WHERE L.station = UPPER('kabc')::VARCHAR
AND L.air_date =
Hi all,
Which one is better (performance/easier to use),
tsearch2 or fulltextindex?
there is an example how to use fulltextindex in the
techdocs, but I checked the contrib/fulltextindex
package, there is a WARNING that fulltextindex is
much slower than tsearch2. but tsearch2 seems
complex to
I was wondering if there is something I can do that would act similar to
a index over more than one table.
I have about 3 million people in my DB at the moment, they all have
roles, and many of them have more than one name.
for example, a Judge will only have one name, but a Litigant could
LIANHE SHAO [EMAIL PROTECTED] writes:
We will have a very large database to store microarray data (may
exceed 80-100G some day). now we have 1G RAM, 2G Hz Pentium 4, 1
CPU. and enough hard disk.
Could anybody tell me that our hardware is an issue or not?
IMHO the size of the DB is less
Jeremiah Jahn kirjutas K, 26.11.2003 kell 22:14:
I was wondering if there is something I can do that would act similar to
a index over more than one table.
I have about 3 million people in my DB at the moment, they all have
roles, and many of them have more than one name.
for example, a
Thanks for reply. Actually our database only supply
some scientists to use (we predict that). so there
is no workload problem. there is only very
infrequent updates. the query is not complex. the
problem is, we have one table that store most of the
data ( with 200 million rows). In this table,
Roger Ging [EMAIL PROTECTED] writes:
Ran vacuum analyse on both program and logfile tables. Estimates are
more in line with reality now,
And they are what now? You really can't expect to get useful help here
when you're being so miserly with the details ...
FWIW, I suspect you could force
On Thu, Nov 27, 2003 at 08:51:14AM +0800, Christopher Kings-Lynne wrote:
Which one is better (performance/easier to use),
tsearch2 or fulltextindex?
there is an example how to use fulltextindex in the
techdocs, but I checked the contrib/fulltextindex
package, there is a WARNING that
Does anyone have any metrics on how fast tsearch2 actually is?
I tried it on a synthetic dataset of a million documents of a hundred
words each and while insertions were impressively fast I gave up on
the search after 10 minutes.
Broken? Unusable slow? This was on the last 7.4 release candidate.
14 matches
Mail list logo
