Sorry Tom, misread your mail! My bad :-(
I believe the following is the data you need ?
Live Server
relname
relpages
ctp_statcon
72
statcon_pk
135
Test
Hi,
I understand that when a table contains only a few rows it is better to
do a sequence scan than an index scan. But is this also for a table with
99 records?
A table contains
id integer (primary key)
namevarchar(70)
Jeroen van Iddekinge wrote:
Hi,
I understand that when a table contains only a few rows it is better to
do a sequence scan than an index scan. But is this also for a table with
99 records?
...
explain select * from tblFolders where id=90;
QUERY PLAN
Hi,
Thanks for respone.
The index scan was a little bit faster for id=1 and faster for id=99.
Which settings shoud I change for this? cpu_index_tuple_cost ,
cpu_operator_cost, cpu_tuple_cost?
You should lower random_page_cost to make the planner choose an index
scan vs sequential scan.
Best
You should lower random_page_cost to make the planner choose an index
scan vs sequential scan.
Yes , it was a bit to high (18) so a lowered it. It speeded up some
pages for about 5%.
Reg. Jer
---(end of broadcast)---
TIP 1: subscribe and
Jeroen van Iddekinge [EMAIL PROTECTED] writes:
You could tweak with several settings to get it to do an index scan
earlier, but these would probably break other queries. You don't need to
tune for 100 rows, morelike 100k or 100M.
Which settings shoud I change for this?
I'd agree with John's
Hi,
Yes , it was a bit to high (18) so a lowered it. It speeded up some
pages for about 5%.
18? The default is 4 if I can remember correctly. I wonder if your db
has ever seen an index scan ;)
Best regards
--
Matteo Beccati
http://phpadsnew.com/
http://phppgads.com/
On Fri, May 06, 2005 at 09:30:46AM +0200, Dennis Bjorklund wrote:
The sql standard include this, except that you can not have the outer ().
So it should be
INSERT INTO table VALUES
(1,2,3),
(4,5,6),
(7,8,9);
Do DB2 demand these extra ()?
My recollection is that it does, but
Matteo Beccati wrote:
Hi,
Yes , it was a bit to high (18) so a lowered it. It speeded up some
pages for about 5%.
18? The default is 4 if I can remember correctly. I wonder if your db
has ever seen an index scan ;)
I was expermenting how much some setting influence has on the perfomance
of
Mischa Sandberg wrote:
After reading the comparisons between Opteron and Xeon processors for Linux,
I'd like to add an Opteron box to our stable of Dells and Sparcs, for
comparison.
IBM, Sun and HP have their fairly pricey Opteron systems.
The IT people are not swell about unsupported purchases
Thanks to everyone for their pointers to suppliers of Opteron systems.
The system I'm pricing is under a tighter budget than a production machine,
because it will be for perftests. Our customers tend to run on Dells but
occasionally run on (Sun) Opterons.
---(end of
Sorry to bother everyone with yet another my query isn't using an
index problem but I am over my head on this one.. I am open to ways
of restructuring this query to perform better.
I have a table, 'ea', with 22 million rows in it. VACUUM ANALYZE has
been just run on the table.
This is the
On Mon, 9 May 2005 09:20 am, Dan Harris wrote:
Sorry to bother everyone with yet another my query isn't using an
index problem but I am over my head on this one.. I am open to ways
of restructuring this query to perform better.
I have a table, 'ea', with 22 million rows in it. VACUUM
Dan,
and ( recordtext like '%RED%' or recordtext like '%CORVETTE%' )
It is simply not possible to use B-tree indexes on these kind of text queries.
B-trees require you to start at the left side of the field, because B-trees
locate records via tests. Anywhere in the field text
Russell Smith [EMAIL PROTECTED] writes:
On Mon, 9 May 2005 09:20 am, Dan Harris wrote:
and ( recordtext like '%RED%' or recordtext like '%CORVETTE%' )
You cannot use an index for %CORVETTE%, or %RED%.
Not a btree index anyway. Dan might have some success here with a
full-text-indexing
On May 8, 2005, at 6:51 PM, Russell Smith wrote:
On Mon, 9 May 2005 09:20 am, Dan Harris wrote:
You cannot use an index for %CORVETTE%, or %RED%. There is no way
for the index to know if a row had that in the middle without scanning
the whole
index. So it's much cheaper to do a sequence scan.
Dan,
While I believe you, I'm confused by this line in my original EXPLAIN
ANALYZE:
- Index Scan using ea1 on ea (cost=0.00..2736.43 rows=42 width=47)
(actual time=2.085..2.309 rows=2 loops=473)
Index Cond:
((ea.incidentid)::text =
Mischa Sandberg wrote:
After reading the comparisons between Opteron and Xeon processors for Linux,
I'd like to add an Opteron box to our stable of Dells and Sparcs, for
comparison.
IBM, Sun and HP have their fairly pricey Opteron systems.
The IT people are not swell about unsupported purchases
Dan Harris [EMAIL PROTECTED] writes:
- Index Scan using ea1 on ea (cost=0.00..2736.43 rows=42 width=47)
(actual time=2.085..2.309 rows=2 loops=473)
Index Cond: ((ea.incidentid)::text = (outer.incidentid)::text)
Filter: (((recordtext)::text ~~ '%RED%'::text) OR
On May 8, 2005, at 8:06 PM, Josh Berkus wrote:
If I were to use tsearch2 for full-text indexing, would I need to
create another table that merges all of my recordtext rows into a
single 'text' field type?
No. Read the OpenFTS docs, they are fairly clear on how to set up a
simple
FTS index.
On Mon, 9 May 2005 11:49 am, Dan Harris wrote:
On May 8, 2005, at 6:51 PM, Russell Smith wrote:
[snip]
select distinct em.incidentid, ea.recordtext as retdata, eg.long,
eg.lat
FROM em JOIN ea ON (em.incidentid = ea.incidentid AND em.entrydate =
'2005-1-1 00:00'
AND em.entrydate
On May 8, 2005, at 8:32 PM, Russell Smith wrote:
I have run this, and while it is very fast, I'm concerned it's not
doing what I need.
How fast is very fast?
It took 35 seconds to complete versus ~450 my old way.
select distinct em.incidentid, ea.recordtext as retdata, eg.long,
eg.lat
FROM em
On Sun, 8 May 2005 20:31:38 -0600, Dan Harris [EMAIL PROTECTED] wrote:
Duly noted. If this method can search across rows, I'm willing to
accept this overhead for the speed it would add.
You could use intersect to search across rows. Using tsearch2 will look
up the RED and CORVETTE using the
23 matches
Mail list logo
