Bill Moran wrote:
In response to Edoardo Ceccarelli <[EMAIL PROTECTED]>:
I have read that autovacuum cannot check to see pg load before launching
vacuum but is there any patch about it? that would sort out the problem
in a good and simple way.
Otherwise, which kind of
Rod Taylor wrote:
On Wed, 2006-09-27 at 18:08 +0200, Edoardo Ceccarelli wrote:
I have read that autovacuum cannot check to see pg load before
launching
vacuum but is there any patch about it? that would sort out the
problem
in a good and simple way.
In some cases the
Hello,
we are running a 7.3 postgres db with only a big table (avg
500.000records) and 7 indexes for a search engine.
we have 2 of this databases and we can switch from one to another.
Last week we decided to give a try to 8.1 on one of them and everything
went fine, db is faster (about 2 or 3
True,
but autovacuum could check load -before- and -during- it's execution and
it could adjust himself automatically to perform more or less
aggressively depending on the difference between those two values.
Maybe with a parameter like: maximum-autovacuum-load=0.2
that would mean: "n
You have 2 seqscans on albumjoin table, you first make a simple join:
...and albumjoin.album = public.album.id ...
that generates the first
-> Seq Scan on albumjoin (cost=0.00..88642.18 rows=5107318 width=8)
and then you group values from same table counting them with
... (select album from a
ng fine, it's 4 month's old with two updates
per week and I vacuum about once per month.
I am using version 7.3 do I need to upgrade to 7.4? also, I was thinking
about setting this table in a kind of "read-only" mode to improve
performance, is this possible?
Thank y
In general we are going to need more information, like what kind of
search filters you are using on the text field and an EXPLAIN ANALYZE.
But can you try and run the following, bearing in mind it will take a
while to complete.
REINDEX TABLE
From what I remember there were issues with index
What happens if you go:
CREATE INDEX annuncio400_rubric_testo_idx ON annuncio400(rubric,
LOWER(testo));
or even just:
CREATE INDEX annuncio400_rubric_testo_idx ON annuncio400(LOWER(testo));
I wasn't able to make this 2 field index with lower:
dba400=# CREATE INDEX annuncio400_rubric_testo_id
tried the
enable_seqscan = false
and I'm having all index scans, timing has improved from 600ms to 18ms
wondering what other implications I might expect.
Edoardo Ceccarelli ha scritto:
What happens if you go:
CREATE INDEX annuncio400_rubric_testo_idx ON annuncio400(rubric,
LOWER(
just created a copy of the same database and it shows that is the
analyze that's messing things:
Slow seqscan query executed on dba400
dba400=# explain analyze SELECT *, oid FROM annuncio400 WHERE rubric =
'DD' AND LOWER(testo) Like LOWER('cbr%') OFFSET 0 LIMIT 11;
can't understand this policy:
dba400=# SELECT count(*) from annuncio400 where rubric='DD';
count
---
6753
(1 row)
dba400=# SELECT count(*) from annuncio400 where rubric='MA';
count
---
2165
(1 row)
so it's using the index on 2000 rows and not for 6000? it's not that
big difference, isn
I am using the oid of the table as the main key and I've found that is
not indexed (maybe because I have declared another primary key in the table)
it is a good practice to create an index like this on the oid of a table?
CREATE INDEX idoid annuncio400 USING btree (oid);
does it work as a normal
I am going to use them as primary key of the table, so I'll surely need
them unique :)
thank you for you help
Edoardo
Dave Cramer ha scritto:
Edoardo,
Are you using them for referential integrity? If so you would be wise to
use sequences instead.
Christopher: yes you are correct, I wasn't sur
do you mean that, declaring an index serial, I'd never have to deal with
incrementing its primary key? good to know!
anyway in this particular situation I don't need such accurate
behaviour: this table is filled up with a lot of data twice per week and
it's used only to answer queries.
I could
This is the query:
select max(KA) from annuncio
field KA is indexed and is int4,
explaining gives:
explain select max(KA) from annuncio;
QUERY PLAN
---
Aggregate (cost=21173.70..21173.70 rows=1 width=4)
-> Seq Scan on annuncio (cos
15 matches
Mail list logo
