-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
| 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 o
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 t
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 JOIN
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
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. (TSe
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 ((reco
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 of
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
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.
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-ind
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"
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. VACU
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
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 bro
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 of
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 som
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 d
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/
---(e
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
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 unsubscr
Jeroen van Iddekinge wrote:
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.
Thanks for respone.
The index scan was a little bit faster for id=1 and faster for id=
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 re
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.
Thanks for respone.
The index scan was a little bit faster for id=1 and faster for id=99.
Which settings shoud I ch
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,
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)
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 Server
26 matches
Mail list logo
