As far as I know the index is only used when you do a prefix search, for
example
col like 'xyz%'
I think that if you are looking for expressions such as 'A%B', you could
rephrase them like this:
col like 'A%' AND col like 'A%B'
So the database could use the index to narrow down the result a
There's a number of sites that have lots of info on postgresql.conf
tuning. Google for 'postgresql.conf tuning' or 'annotated
postgresql.conf'.
I know some of these sites, but who should I know if the information on
those pages is correct? The information on those pages should be
published as
Hi,
hi,
I'm curious as to why autovacuum is not designed to do full vacuum. I
Because nothing that runs automatically should ever take an exclusive
lock on the entire database, which is what VACUUM FULL does.
I thought that vacuum full only locks the table which it currently
operates on?
Well,
I think that the documentation is not exactly easy to understand. I
always wondered why there are no examples for common postgresql
configurations. All I know is that the default configuration seems to be
too low for production use. And while running postgres I get no hints as
to which
Hi,
yes, some heavily used tables contain approx. 90% free space after a
week. I'll try to increase FSM even more, but I think that I will still
have to run a full vacuum every week. Prior to 8.1 I was using 7.4 and
ran a full vacuum every day, so the autovacuum has helped a lot.
But actuall
VACUUM FULL blocks the application. That is NOT something that anyone
wants to throw into the "activity mix" randomly.
There must be a way to implement a daemon which frees up space of a
relation without blocking it too long. It could abort after a certain
number of blocks have been freed a
Hi,
did you read my post? In the first part I explained why I don't want to
increase the FSM that much.
Mike
So my question is: What's the use of an autovacuum daemon if I still
have to use a cron job to do full vacuums? wouldn't it just be a minor
job to enhance autovacuum to be able to pe
hi,
I'm curious as to why autovacuum is not designed to do full vacuum. I
know that the necessity of doing full vacuums can be reduced by
increasing the FSM, but in my opinion that is the wrong decision for
many applications. My application does not continuously
insert/update/delete tuples at
nks again!
Mike
On Mon, 16 Jan 2006 15:36:53 +0100
Michael Riess <[EMAIL PROTECTED]> wrote:
Hi,
I've been reading an interesting article which compared different
database systems, focusing on materialized views. I was wondering how
the postgresql developers feel about this feature
Hi,
I've been reading an interesting article which compared different
database systems, focusing on materialized views. I was wondering how
the postgresql developers feel about this feature ... is it planned to
implement materialized views any time soon? They would greatly improve
both perfor
Markus Schaber schrieb:
Hello,
We have a database containing PostGIS MAP data, it is accessed mainly
via JDBC. There are multiple simultaneous read-only connections taken
from the JBoss connection pooling, and there usually are no active
writers. We use connection.setReadOnly(true).
Now my ques
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.
No, my problem is that using TSearch2 interferes with other core
components of postgres like (auto)vacuum or dump/restore.
...
So you'll avoid a non-core product and instead only use another non-core
product...?
Chris
Michael Riess wrote:
Has anyone ever compared TSearch2 to Lucen
Ameet Kini schrieb:
This didn't get through the first time around, so resending it again.
Sorry for any duplicate entries.
Hello,
I have a question on postgres's performance tuning, in particular, the
vacuum and reindex commands. Currently I do a vacuum (without full) on all
of my tables.
Bruce Momjian schrieb:
Oleg Bartunov wrote:
Folks,
tsearch2 and Lucene are very different search engines, so it'd be unfair
comparison. If you need full access to metadata and instant indexing
you, probably, find tsearch2 is more suitable then Lucene. But, if
you could live without that featur
Has anyone ever compared TSearch2 to Lucene, as far as performance is
concerned?
I'll stay away from TSearch2 until it is fully integrated in the
postgres core (like "create index foo_text on foo (texta, textb) USING
TSearch2"). Because a full integration is unlikely to happen in the near
f
Hi,
Is it possible to get this query run faster than it does now, by adding
indexes, changing the query?
SELECT customers.objectid FROM prototype.customers, prototype.addresses
WHERE
customers.contactaddress = addresses.objectid
ORDER BY zipCode asc, housenumber asc
LIMIT 1 OFFSET 283745
Explai
William Yu schrieb:
> Michael Riess wrote:
>>> Well, I'd think that's were your problem is. Not only you have a
>>> (relatively speaking) small server -- you also share it with other
>>> very-memory-hungry services! That's not a situation I'
Alvaro Herrera schrieb:
Michael Riess wrote:
Shared memory ... I currently use 1500 buffers for 50 connections, and
performance really suffered when I used 3000 buffers. The problem is
that it is a 1GB machine, and Apache + Tomcat need about 400MB.
Well, I'd think that's were yo
Jan Wieck schrieb:
On 12/2/2005 6:01 PM, Michael Riess wrote:
Hi,
thanks for your comments so far - I appreciate it. I'd like to narrow
down my problem a bit:
As I said in the other thread, I estimate that only 20% of the 15,000
tables are accessed regularly. So I don't
Hi,
thanks for your comments so far - I appreciate it. I'd like to narrow
down my problem a bit:
As I said in the other thread, I estimate that only 20% of the 15,000
tables are accessed regularly. So I don't think that vacuuming or the
number of file handles is a problem. Have a look at thi
Michael Riess <[EMAIL PROTECTED]> writes:
On 12/1/05, Michael Riess <[EMAIL PROTECTED]> wrote:
we are currently running a postgres server (upgraded to 8.1) which
has one large database with approx. 15,000 tables. Unfortunately
performance suffers from that, because the int
Hi Tom,
Michael Riess <[EMAIL PROTECTED]> writes:
(We NEED that many tables, please don't recommend to reduce them)
No, you don't. Add an additional key column to fold together different
tables of the same structure. This will be much more efficient than
managing that key a
Hi,
On 12/1/05, Michael Riess <[EMAIL PROTECTED]> wrote:
Hi,
we are currently running a postgres server (upgraded to 8.1) which has
one large database with approx. 15,000 tables. Unfortunately performance
suffers from that, because the internal tables (especially that which
hol
Hi David,
with 15,000 tables you are talking about a LOT of files to hold these
(30,000 files with one index each and each database being small enough
to not need more then one file to hold it), on linux ext2/3 this many
files in one directory will slow you down horribly.
We use ReiserFS,
Hi David,
incidentally: The directory which holds our datbase currently contains
73883 files ... do I get a prize or something? ;-)
Regards,
Mike
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Hi,
we are currently running a postgres server (upgraded to 8.1) which has
one large database with approx. 15,000 tables. Unfortunately performance
suffers from that, because the internal tables (especially that which
holds the attribute info) get too large.
(We NEED that many tables, please
27 matches
Mail list logo
