Hello Arjen.
Thank you for replying.
I'll try OR query on my environment.
Thanks.
2016年1月4日(月) 23:03 Arjen Nienhuis :
>
> On Jan 4, 2016 09:45, "Hiroyuki Sato" wrote:
> >
> > Hello Arjen
> >
> > Thank you for replying.
> >
> > 2016年1月4日(月) 16:49 Arjen Nienhuis :
> >>
> >>
> >> On Dec 28, 201
On Jan 4, 2016 09:45, "Hiroyuki Sato" wrote:
>
> Hello Arjen
>
> Thank you for replying.
>
> 2016年1月4日(月) 16:49 Arjen Nienhuis :
>>
>>
>> On Dec 28, 2015 00:55, "Hiroyuki Sato" wrote:
>> >
>> > Hello Andreas and Tom
>> >
>> > Thank you for replying.
>> >
>> > Sorry, I re-created my questions. I w
Hello Arjen
Thank you for replying.
2016年1月4日(月) 16:49 Arjen Nienhuis :
>
> On Dec 28, 2015 00:55, "Hiroyuki Sato" wrote:
> >
> > Hello Andreas and Tom
> >
> > Thank you for replying.
> >
> > Sorry, I re-created my questions. I was mis-pasted query log on previous
> question.
> > (@~ operator i
Hello David
Thank your for your comment.
2015年12月30日(水) 10:15 David Rowley :
> On 30 December 2015 at 13:56, Hiroyuki Sato wrote:
>
>> 2015年12月30日(水) 6:04 David Rowley :
>>
>>> On 30 December 2015 at 04:21, Hiroyuki Sato wrote:
>>>
2015年12月29日(火) 4:35 Jeff Janes :
>
>
Bu
On Dec 28, 2015 00:55, "Hiroyuki Sato" wrote:
>
> Hello Andreas and Tom
>
> Thank you for replying.
>
> Sorry, I re-created my questions. I was mis-pasted query log on previous
question.
> (@~ operator is PGroonga extension (http://pgroonga.github.io))
> Please ignore it.
>
> Best regards.
>
> 1,
On 30 December 2015 at 13:56, Hiroyuki Sato wrote:
> 2015年12月30日(水) 6:04 David Rowley :
>
>> On 30 December 2015 at 04:21, Hiroyuki Sato wrote:
>>
>>> 2015年12月29日(火) 4:35 Jeff Janes :
>>>
>>> But, the planner refuses to use this index for your query anyway,
because it can't see th
Hello David
Thank you for replying.
2015年12月30日(水) 6:04 David Rowley :
> On 30 December 2015 at 04:21, Hiroyuki Sato wrote:
>
>> 2015年12月29日(火) 4:35 Jeff Janes :
>>
>>>
>>>
>> But, the planner refuses to use this index for your query anyway,
>>> because it can't see that the patterns are all le
On 30 December 2015 at 04:21, Hiroyuki Sato wrote:
> 2015年12月29日(火) 4:35 Jeff Janes :
>
>>
>>
>
>> But, the planner refuses to use this index for your query anyway,
>> because it can't see that the patterns are all left-anchored.
>>
>> Really, your best bet is refactor your url data so it is stor
Hello Jeff
Thank you for replying.
2015年12月29日(火) 4:35 Jeff Janes :
> On Sun, Dec 27, 2015 at 3:53 PM, Hiroyuki Sato
> wrote:
> > Hello Andreas and Tom
> >
> > Thank you for replying.
> >
> > Sorry, I re-created my questions. I was mis-pasted query log on previous
> > question.
> > (@~ operator
Hello Tom.
Thank you for replying.
This is Gin Index result.
It is slow too.
Best regards.
--
Hiroyuki Sato
1, create.sql
drop table if exists url_lists4;
create table url_lists4 (
id int not null primary key,
url text not null
);
--create index ix_url_url_lists4
On Sun, Dec 27, 2015 at 3:53 PM, Hiroyuki Sato wrote:
> Hello Andreas and Tom
>
> Thank you for replying.
>
> Sorry, I re-created my questions. I was mis-pasted query log on previous
> question.
> (@~ operator is PGroonga extension (http://pgroonga.github.io))
> Please ignore it.
>
> Best regards.
Hiroyuki Sato writes:
> I re-created index with pg_trgm.
> Execution time is 210sec.
> Yes It is faster than btree index. But still slow.
> It is possible to improve this query speed?
> Should I use another query or idex?
Did you try a GIN index?
regards, tom lane
--
S
Hello Tom.
Thank you for replying.
I re-created index with pg_trgm.
Execution time is 210sec.
Yes It is faster than btree index. But still slow.
It is possible to improve this query speed?
Should I use another query or idex?
Best regards.
1, query
SELECT
u.url
FROM
url_list
Hiroyuki Sato writes:
> Sorry, I re-created my questions. I was mis-pasted query log on previous
> question.
> (@~ operator is PGroonga extension (http://pgroonga.github.io))
> [ "like" is actually the operator of interest ]
Ah. You might get some good results with trigram indexes (ie,
contrib/p
Hello Andreas and Tom
Thank you for replying.
Sorry, I re-created my questions. I was mis-pasted query log on previous
question.
(@~ operator is PGroonga extension (http://pgroonga.github.io))
Please ignore it.
Best regards.
1, Problem.
(1) Following query is exteme slow. (478sec)
SELECT
Andreas Kretschmer writes:
>> Tom Lane hat am 27. Dezember 2015 um 19:11 geschrieben:
>> What in the world is this @~ operator? And what sort of index are
>> you using now, that can accept it? Are the rowcount estimates in
>> the EXPLAIN output accurate? (If they are, it's hardly surprising
>>
> Tom Lane hat am 27. Dezember 2015 um 19:11 geschrieben:
>
>
> Hiroyuki Sato writes:
> > I would like to create the query like the following.
> > It work well, but extreme slow.
> > ...
> > Explain output.
>
> > Nested Loop (cost=0.45..1570856063.28 rows=5712200 width=57)
> >-> I
Hiroyuki Sato writes:
> I would like to create the query like the following.
> It work well, but extreme slow.
> ...
> Explain output.
> Nested Loop (cost=0.45..1570856063.28 rows=5712200 width=57)
>-> Index Scan using ix_name_keywords on keywords k (cost=0.28..221.78
> rows=5000 wid
Hiroyuki Sato wrote:
> Hello.
>
> I would like to create the query like the following.
> It work well, but extreme slow.
> Is it possible to improve this query like the command ``grep -f keyword
> data``?
>
> What kind of Index should I create on url_lists table?
can you show us the create ta
Hello.
I would like to create the query like the following.
It work well, but extreme slow.
Is it possible to improve this query like the command ``grep -f keyword
data``?
What kind of Index should I create on url_lists table?
Detail
https://gist.github.com/hiroyuki-sato/574b8ea5d9396e455d60
SE
20 matches
Mail list logo
