///I put index in a fiel named tags $ma_collection->ensureIndex("tags");
This is the code when php reads documents :
///Research of documents who containts key words $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x")); $db = $cnx_mongo->my_database; $ma_collection = $db->my_collection;
//Get back keywords researching by tags fields $who = array(); if(count($ArrayWord) > 1) { $tmp = array(); foreach ($ArrayWord as $q) { $tmp[] = new MongoRegex( "/". strtolower($q) ."/" ); }
$who['tags'] = array('$all' => $tmp);
}else{ $who['tags'] = new MongoRegex( "/". strtolower($mot) ."/" ); }
As you did correctly, if this is not a live production database, you can ensureIndex() after you finish the batch. Because if there's an index, the database needs to update the index every time there is new document inserted.
Is it possible, and i'm just wondering here, that PostgreSQL is one of the causes of the batch being slow? If not do you have any more information on why is not?
I don't think that Postgres causes the bach being slow, because when I use MongoDB as a reseach engin to research documents by keywords ,
my reseach engin is very slow or ends with an error of timeout : *Fatal error: Uncaught exception 'MongoCursorTimeoutException' with message 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'* .
> As you did correctly, if this is not a live production database, you > can ensureIndex() after you finish the batch.
> Because if there's an index, the database needs to update the index every > time there is new document inserted.
> Is it possible, and i'm just wondering here, that PostgreSQL is one of the > causes of the batch being slow?
> If not do you have any more information on why is not?
> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>> Good afternoon,
>> I'am using MongoDB with 350 000 documents and php. The problem is the php >> reads documents very slowly .
>> When I'm updating documents I drop the database and I insert the >> documents : during this processus the inserts are very long .
>> I don't understand, I putted indexes .
>> I show you a piece of my php code when I updating documents :
>> $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x"));
If you run explain() on the cursor you can see why is taking that long.
var_dump($cursor->explain());
Do that on one and see if it's using an index (BtreeCursor)
Another problem could be that you are limiting the find() results to 30 and then doing a skip.
This is not every efficient, and I don't understand from your code exactly why are you doing that.
You can also try to increase the timeout of the cursor and try if that helps
On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
> I don't think that Postgres causes the bach being slow, because when I use > MongoDB as a reseach engin to research documents by keywords ,
> my reseach engin is very slow or ends with an error of timeout : *Fatal > error: Uncaught exception 'MongoCursorTimeoutException' with message > 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'* .
> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>> As you did correctly, if this is not a live production database, you >> can ensureIndex() after you finish the batch.
>> Because if there's an index, the database needs to update the index every >> time there is new document inserted.
>> Is it possible, and i'm just wondering here, that PostgreSQL is one of >> the causes of the batch being slow?
>> If not do you have any more information on why is not?
>> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>>> Good afternoon,
>>> I'am using MongoDB with 350 000 documents and php. The problem is the >>> php reads documents very slowly .
>>> When I'm updating documents I drop the database and I insert the >>> documents : during this processus the inserts are very long .
>>> I don't understand, I putted indexes .
>>> I show you a piece of my php code when I updating documents :
>>> $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x"));
> If you run explain() on the cursor you can see why is taking that long.
> var_dump($cursor->explain());
> Do that on one and see if it's using an index (BtreeCursor)
> Another problem could be that you are limiting the find() results to 30 > and then doing a skip.
> This is not every efficient, and I don't understand from your code exactly > why are you doing that.
> You can also try to increase the timeout of the cursor and try if that > helps
> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>> I don't think that Postgres causes the bach being slow, because when I >> use MongoDB as a reseach engin to research documents by keywords ,
>> my reseach engin is very slow or ends with an error of timeout : *Fatal >> error: Uncaught exception 'MongoCursorTimeoutException' with message >> 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'* .
>> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>>> As you did correctly, if this is not a live production database, you >>> can ensureIndex() after you finish the batch.
>>> Because if there's an index, the database needs to update the index >>> every time there is new document inserted.
>>> Is it possible, and i'm just wondering here, that PostgreSQL is one of >>> the causes of the batch being slow?
>>> If not do you have any more information on why is not?
>>> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>>>> Good afternoon,
>>>> I'am using MongoDB with 350 000 documents and php. The problem is the >>>> php reads documents very slowly .
>>>> When I'm updating documents I drop the database and I insert the >>>> documents : during this processus the inserts are very long .
>>>> I don't understand, I putted indexes .
>>>> I show you a piece of my php code when I updating documents :
>>>> $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x"));
> Le lundi 10 septembre 2012 17:31:40 UTC+2, Gianfranco a écrit :
>> If you run explain() on the cursor you can see why is taking that long.
>> var_dump($cursor->explain());
>> Do that on one and see if it's using an index (BtreeCursor)
>> Another problem could be that you are limiting the find() results to 30 >> and then doing a skip.
>> This is not every efficient, and I don't understand from your code >> exactly why are you doing that.
>> You can also try to increase the timeout of the cursor and try if that >> helps
>> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>>> I don't think that Postgres causes the bach being slow, because when I >>> use MongoDB as a reseach engin to research documents by keywords ,
>>> my reseach engin is very slow or ends with an error of timeout : *Fatal >>> error: Uncaught exception 'MongoCursorTimeoutException' with message >>> 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'* .
>>> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>>>> As you did correctly, if this is not a live production database, you >>>> can ensureIndex() after you finish the batch.
>>>> Because if there's an index, the database needs to update the index >>>> every time there is new document inserted.
>>>> Is it possible, and i'm just wondering here, that PostgreSQL is one of >>>> the causes of the batch being slow?
>>>> If not do you have any more information on why is not?
>>>> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>>>>> Good afternoon,
>>>>> I'am using MongoDB with 350 000 documents and php. The problem is the >>>>> php reads documents very slowly .
>>>>> When I'm updating documents I drop the database and I insert the >>>>> documents : during this processus the inserts are very long .
>>>>> I don't understand, I putted indexes .
>>>>> I show you a piece of my php code when I updating documents :
>>>>> $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x"));
>> I am limiting the find to avoid display every documents in the same page >> .
> Hi > "BasicCursor" implies your index didn't work for your query.
>> Le lundi 10 septembre 2012 17:31:40 UTC+2, Gianfranco a écrit :
>>> If you run explain() on the cursor you can see why is taking that long.
>>> var_dump($cursor->explain());
>>> Do that on one and see if it's using an index (BtreeCursor)
>>> Another problem could be that you are limiting the find() results to 30 >>> and then doing a skip.
>>> This is not every efficient, and I don't understand from your code >>> exactly why are you doing that.
>>> You can also try to increase the timeout of the cursor and try if that >>> helps
>>> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>>>> I don't think that Postgres causes the bach being slow, because when I >>>> use MongoDB as a reseach engin to research documents by keywords ,
>>>> my reseach engin is very slow or ends with an error of timeout : *Fatal >>>> error: Uncaught exception 'MongoCursorTimeoutException' with message >>>> 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'* .
>>>> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>>>>> As you did correctly, if this is not a live production database, you >>>>> can ensureIndex() after you finish the batch.
>>>>> Because if there's an index, the database needs to update the index >>>>> every time there is new document inserted.
>>>>> Is it possible, and i'm just wondering here, that PostgreSQL is one of >>>>> the causes of the batch being slow?
>>>>> If not do you have any more information on why is not?
>>>>> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>>>>>> Good afternoon,
>>>>>> I'am using MongoDB with 350 000 documents and php. The problem is the >>>>>> php reads documents very slowly .
>>>>>> When I'm updating documents I drop the database and I insert the >>>>>> documents : during this processus the inserts are very long .
>>>>>> I don't understand, I putted indexes .
>>>>>> I show you a piece of my php code when I updating documents :
>>>>>> $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x"));
But, how can I get a BtreeCursor with ensureIndex() function ?
Whitch arguments can I put in this function, I know that I have to give the field name in the first argument .
Le lundi 10 septembre 2012 18:01:33 UTC+2, Gianfranco a écrit :
>>> I am limiting the find to avoid display every documents in the same page >>> .
>> Hi >> "BasicCursor" implies your index didn't work for your query.
>>> Le lundi 10 septembre 2012 17:31:40 UTC+2, Gianfranco a écrit :
>>>> If you run explain() on the cursor you can see why is taking that long.
>>>> var_dump($cursor->explain());
>>>> Do that on one and see if it's using an index (BtreeCursor)
>>>> Another problem could be that you are limiting the find() results to 30 >>>> and then doing a skip.
>>>> This is not every efficient, and I don't understand from your code >>>> exactly why are you doing that.
>>>> You can also try to increase the timeout of the cursor and try if that >>>> helps
>>>> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>>>>> I don't think that Postgres causes the bach being slow, because when I >>>>> use MongoDB as a reseach engin to research documents by keywords ,
>>>>> my reseach engin is very slow or ends with an error of timeout : *Fatal >>>>> error: Uncaught exception 'MongoCursorTimeoutException' with message >>>>> 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'* .
>>>>> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>>>>>> As you did correctly, if this is not a live production database, you >>>>>> can ensureIndex() after you finish the batch.
>>>>>> Because if there's an index, the database needs to update the index >>>>>> every time there is new document inserted.
>>>>>> Is it possible, and i'm just wondering here, that PostgreSQL is one >>>>>> of the causes of the batch being slow?
>>>>>> If not do you have any more information on why is not?
>>>>>> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>>>>>>> Good afternoon,
>>>>>>> I'am using MongoDB with 350 000 documents and php. The problem is >>>>>>> the php reads documents very slowly .
>>>>>>> When I'm updating documents I drop the database and I insert the >>>>>>> documents : during this processus the inserts are very long .
>>>>>>> I don't understand, I putted indexes .
>>>>>>> I show you a piece of my php code when I updating documents :
>>>>>>> $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x"));
> But, how can I get a BtreeCursor with ensureIndex() function ?
> Whitch arguments can I put in this function, I know that I have to give
> the field name in the first argument .
> Le lundi 10 septembre 2012 18:01:33 UTC+2, Gianfranco a écrit :
>> Yes, as Gelin said.
>> That query is not using an index, that's why is taking longer, going
>> through the entire collection.
>> Make sure you ensureIndex() on the correct fields.
>> Then try doing an explain again to check if it worked
>> On Monday, September 10, 2012 4:52:28 PM UTC+1, gelin yan wrote:
>>>> I am limiting the find to avoid display every documents in the same
>>>> page .
>>> Hi
>>> "BasicCursor" implies your index didn't work for your query.
>>>> Le lundi 10 septembre 2012 17:31:40 UTC+2, Gianfranco a écrit :
>>>>> If you run explain() on the cursor you can see why is taking that long.
>>>>> var_dump($cursor->explain());
>>>>> Do that on one and see if it's using an index (BtreeCursor)
>>>>> Another problem could be that you are limiting the find() results to
>>>>> 30 and then doing a skip.
>>>>> This is not every efficient, and I don't understand from your code
>>>>> exactly why are you doing that.
>>>>> You can also try to increase the timeout of the cursor and try if that
>>>>> helps
>>>>> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>>>>>> I don't think that Postgres causes the bach being slow, because when
>>>>>> I use MongoDB as a reseach engin to research documents by keywords ,
>>>>>> my reseach engin is very slow or ends with an error of timeout : *Fatal
>>>>>> error: Uncaught exception 'MongoCursorTimeoutException' with message
>>>>>> 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'* .
>>>>>> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>>>>>>> As you did correctly, if this is not a live production database, you
>>>>>>> can ensureIndex() after you finish the batch.
>>>>>>> Because if there's an index, the database needs to update the index
>>>>>>> every time there is new document inserted.
>>>>>>> Is it possible, and i'm just wondering here, that PostgreSQL is one
>>>>>>> of the causes of the batch being slow?
>>>>>>> If not do you have any more information on why is not?
>>>>>>> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>>>>>>>> Good afternoon,
>>>>>>>> I'am using MongoDB with 350 000 documents and php. The problem is
>>>>>>>> the php reads documents very slowly .
>>>>>>>> When I'm updating documents I drop the database and I insert the
>>>>>>>> documents : during this processus the inserts are very long .
>>>>>>>> I don't understand, I putted indexes .
>>>>>>>> I show you a piece of my php code when I updating documents :
>>>>>>>> $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x"));
>>>>>>>> print($cursor->count()); // I display the number of documents
>>>>>>>> foreach($cursor as $obj){
>>>>>>>> ///I display the results of document
>>>>>>>> }
>>>>>>>> The tags field containts array keywords .
>>>>>>>> What should I do to resolve this problem ?
>>>>>>>> I checked the RAM (6 Go of physical RAM and 4 Go of available
>>>>>>>> memory) .
>>>>>>>> How can I check the cause of this slow reads and inserts ?
>>>>>>>> I there is something to configure in mongodb ?
>>>>>>>> Best regards .
>>>>>>> --
> You received this message because you are subscribed to the Google
> Groups "mongodb-user" group.
> To post to this group, send email to mongodb-user@googlegroups.com
> To unsubscribe from this group, send email to
> mongodb-user+unsubscribe@googlegroups.com
> See also the IRC channel -- freenode.net#mongodb
In this code I am trying is to research only documents that have all keywords asked by the client,
For example a user who is looking for documents, when he types "windows 2008 Server R2 Datacenter" or "win 2008 Server R Data" the research engin have to
display documents that contains the following keywords : array(0 => windows, 2008, Server, R2, Datacenter) contained in the "tags" field (It is an array)
Le lundi 10 septembre 2012 21:14:11 UTC+2, Sammaye a écrit :
> On 10 September 2012 20:10, marcandre <male...@gmail.com <javascript:>>wrote:
>> Thank you very much for these informations,
>> But, how can I get a BtreeCursor with ensureIndex() function ?
>> Whitch arguments can I put in this function, I know that I have to give >> the field name in the first argument .
>> Le lundi 10 septembre 2012 18:01:33 UTC+2, Gianfranco a écrit :
>>> Yes, as Gelin said.
>>> That query is not using an index, that's why is taking longer, going >>> through the entire collection.
>>> Make sure you ensureIndex() on the correct fields.
>>> Then try doing an explain again to check if it worked
>>> On Monday, September 10, 2012 4:52:28 PM UTC+1, gelin yan wrote:
>>>>> I am limiting the find to avoid display every documents in the same >>>>> page .
>>>> Hi >>>> "BasicCursor" implies your index didn't work for your query.
>>>>> Le lundi 10 septembre 2012 17:31:40 UTC+2, Gianfranco a écrit :
>>>>>> If you run explain() on the cursor you can see why is taking that >>>>>> long.
>>>>>> var_dump($cursor->explain());
>>>>>> Do that on one and see if it's using an index (BtreeCursor)
>>>>>> Another problem could be that you are limiting the find() results to >>>>>> 30 and then doing a skip.
>>>>>> This is not every efficient, and I don't understand from your code >>>>>> exactly why are you doing that.
>>>>>> You can also try to increase the timeout of the cursor and try if >>>>>> that helps
>>>>>> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>>>>>>> I don't think that Postgres causes the bach being slow, because when >>>>>>> I use MongoDB as a reseach engin to research documents by keywords ,
>>>>>>> my reseach engin is very slow or ends with an error of timeout : *Fatal >>>>>>> error: Uncaught exception 'MongoCursorTimeoutException' with message >>>>>>> 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'* .
>>>>>>> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>>>>>>>> As you did correctly, if this is not a live production database, >>>>>>>> you can ensureIndex() after you finish the batch.
>>>>>>>> Because if there's an index, the database needs to update the index >>>>>>>> every time there is new document inserted.
>>>>>>>> Is it possible, and i'm just wondering here, that PostgreSQL is one >>>>>>>> of the causes of the batch being slow?
>>>>>>>> If not do you have any more information on why is not?
>>>>>>>> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>>>>>>>>> Good afternoon,
>>>>>>>>> I'am using MongoDB with 350 000 documents and php. The problem is >>>>>>>>> the php reads documents very slowly .
>>>>>>>>> When I'm updating documents I drop the database and I insert the >>>>>>>>> documents : during this processus the inserts are very long .
>>>>>>>>> I don't understand, I putted indexes .
>>>>>>>>> I show you a piece of my php code when I updating documents :
>>>>>>>>> $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x"));
>>>>>>>>> print($cursor->count()); // I display the number of documents
>>>>>>>>> foreach($cursor as $obj){
>>>>>>>>> ///I display the results of document
>>>>>>>>> }
>>>>>>>>> The tags field containts array keywords .
>>>>>>>>> What should I do to resolve this problem ?
>>>>>>>>> I checked the RAM (6 Go of physical RAM and 4 Go of available >>>>>>>>> memory) .
>>>>>>>>> How can I check the cause of this slow reads and inserts ?
>>>>>>>>> I there is something to configure in mongodb ?
>>>>>>>>> Best regards .
>>>>>>>> -- >> You received this message because you are subscribed to the Google
>> Groups "mongodb-user" group.
>> To post to this group, send email to mongod...@googlegroups.com<javascript:>
>> To unsubscribe from this group, send email to
>> mongodb-user...@googlegroups.com <javascript:>
>> See also the IRC channel -- freenode.net#mongodb
> In this code I am trying is to research only documents that have all
> keywords asked by the client,
> For example a user who is looking for documents, when he types "windows
> 2008 Server R2 Datacenter" or "win 2008 Server R Data" the research engin
> have to
> display documents that contains the following keywords : array(0 =>
> windows, 2008, Server, R2, Datacenter) contained in the "tags" field (It
> is an array)
> Le lundi 10 septembre 2012 21:14:11 UTC+2, Sammaye a écrit :
>> Non-prefixed regexes do not use indexes would be one of your problems:
>> On 10 September 2012 20:10, marcandre <male...@gmail.com> wrote:
>>> Thank you very much for these informations,
>>> But, how can I get a BtreeCursor with ensureIndex() function ?
>>> Whitch arguments can I put in this function, I know that I have to give
>>> the field name in the first argument .
>>> Le lundi 10 septembre 2012 18:01:33 UTC+2, Gianfranco a écrit :
>>>> Yes, as Gelin said.
>>>> That query is not using an index, that's why is taking longer, going
>>>> through the entire collection.
>>>> Make sure you ensureIndex() on the correct fields.
>>>> Then try doing an explain again to check if it worked
>>>> On Monday, September 10, 2012 4:52:28 PM UTC+1, gelin yan wrote:
>>>>>> I am limiting the find to avoid display every documents in the same
>>>>>> page .
>>>>> Hi
>>>>> "BasicCursor" implies your index didn't work for your query.
>>>>>> Le lundi 10 septembre 2012 17:31:40 UTC+2, Gianfranco a écrit :
>>>>>>> If you run explain() on the cursor you can see why is taking that
>>>>>>> long.
>>>>>>> var_dump($cursor->explain());
>>>>>>> Do that on one and see if it's using an index (BtreeCursor)
>>>>>>> Another problem could be that you are limiting the find() results to
>>>>>>> 30 and then doing a skip.
>>>>>>> This is not every efficient, and I don't understand from your code
>>>>>>> exactly why are you doing that.
>>>>>>> You can also try to increase the timeout of the cursor and try if
>>>>>>> that helps
>>>>>>> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>>>>>>>> I don't think that Postgres causes the bach being slow, because
>>>>>>>> when I use MongoDB as a reseach engin to research documents by keywords ,
>>>>>>>> my reseach engin is very slow or ends with an error of timeout : *Fatal
>>>>>>>> error: Uncaught exception 'MongoCursorTimeoutException' with message
>>>>>>>> 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'* .
>>>>>>>> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>>>>>>>>> As you did correctly, if this is not a live production database,
>>>>>>>>> you can ensureIndex() after you finish the batch.
>>>>>>>>> Because if there's an index, the database needs to update the
>>>>>>>>> index every time there is new document inserted.
>>>>>>>>> Is it possible, and i'm just wondering here, that PostgreSQL is
>>>>>>>>> one of the causes of the batch being slow?
>>>>>>>>> If not do you have any more information on why is not?
>>>>>>>>> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>>>>>>>>>> Good afternoon,
>>>>>>>>>> I'am using MongoDB with 350 000 documents and php. The problem is
>>>>>>>>>> the php reads documents very slowly .
>>>>>>>>>> When I'm updating documents I drop the database and I insert the
>>>>>>>>>> documents : during this processus the inserts are very long .
>>>>>>>>>> I don't understand, I putted indexes .
>>>>>>>>>> I show you a piece of my php code when I updating documents :
>>>>>>>>>> $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x"));
>>>>>>>>>> print($cursor->count()); // I display the number of documents
>>>>>>>>>> foreach($cursor as $obj){
>>>>>>>>>> ///I display the results of document
>>>>>>>>>> }
>>>>>>>>>> The tags field containts array keywords .
>>>>>>>>>> What should I do to resolve this problem ?
>>>>>>>>>> I checked the RAM (6 Go of physical RAM and 4 Go of available
>>>>>>>>>> memory) .
>>>>>>>>>> How can I check the cause of this slow reads and inserts ?
>>>>>>>>>> I there is something to configure in mongodb ?
>>>>>>>>>> Best regards .
>>>>>>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "mongodb-user" group.
>>> To post to this group, send email to mongod...@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> mongodb-user...@**googlegroups.com
>>> See also the IRC channel -- freenode.net#mongodb
>> --
> You received this message because you are subscribed to the Google
> Groups "mongodb-user" group.
> To post to this group, send email to mongodb-user@googlegroups.com
> To unsubscribe from this group, send email to
> mongodb-user+unsubscribe@googlegroups.com
> See also the IRC channel -- freenode.net#mongodb
Basically I understand what your trying to do, essentially an FTS. Problem
is the infixing on your fields is 2 characters min so "win 2008 Server R
Data" won't match without regex. I strongely suggest you either deal with
out regex or you split up your words further, but then they could lose
their meaning and return superflious amount of documents.
On 10 September 2012 20:50, Sam Millman <sam.mill...@gmail.com> wrote:
> If it is an array of words then you don't need the regex, try taking that
> out.
> On 10 September 2012 20:44, marcandre <malegr...@gmail.com> wrote:
>> In this code I am trying is to research only documents that have all
>> keywords asked by the client,
>> For example a user who is looking for documents, when he types "windows
>> 2008 Server R2 Datacenter" or "win 2008 Server R Data" the research engin
>> have to
>> display documents that contains the following keywords : array(0 =>
>> windows, 2008, Server, R2, Datacenter) contained in the "tags" field (It
>> is an array)
>> Le lundi 10 septembre 2012 21:14:11 UTC+2, Sammaye a écrit :
>>> Non-prefixed regexes do not use indexes would be one of your problems:
>>> On 10 September 2012 20:10, marcandre <male...@gmail.com> wrote:
>>>> Thank you very much for these informations,
>>>> But, how can I get a BtreeCursor with ensureIndex() function ?
>>>> Whitch arguments can I put in this function, I know that I have to give
>>>> the field name in the first argument .
>>>> Le lundi 10 septembre 2012 18:01:33 UTC+2, Gianfranco a écrit :
>>>>> Yes, as Gelin said.
>>>>> That query is not using an index, that's why is taking longer, going
>>>>> through the entire collection.
>>>>> Make sure you ensureIndex() on the correct fields.
>>>>> Then try doing an explain again to check if it worked
>>>>> On Monday, September 10, 2012 4:52:28 PM UTC+1, gelin yan wrote:
>>>>>>> I am limiting the find to avoid display every documents in the same
>>>>>>> page .
>>>>>> Hi
>>>>>> "BasicCursor" implies your index didn't work for your query.
>>>>>>> Le lundi 10 septembre 2012 17:31:40 UTC+2, Gianfranco a écrit :
>>>>>>>> If you run explain() on the cursor you can see why is taking that
>>>>>>>> long.
>>>>>>>> var_dump($cursor->explain());
>>>>>>>> Do that on one and see if it's using an index (BtreeCursor)
>>>>>>>> Another problem could be that you are limiting the find() results
>>>>>>>> to 30 and then doing a skip.
>>>>>>>> This is not every efficient, and I don't understand from your code
>>>>>>>> exactly why are you doing that.
>>>>>>>> You can also try to increase the timeout of the cursor and try if
>>>>>>>> that helps
>>>>>>>> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>>>>>>>>> I don't think that Postgres causes the bach being slow, because
>>>>>>>>> when I use MongoDB as a reseach engin to research documents by keywords ,
>>>>>>>>> my reseach engin is very slow or ends with an error of timeout : *Fatal
>>>>>>>>> error: Uncaught exception 'MongoCursorTimeoutException' with message
>>>>>>>>> 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'* .
>>>>>>>>> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>>>>>>>>>> As you did correctly, if this is not a live production database,
>>>>>>>>>> you can ensureIndex() after you finish the batch.
>>>>>>>>>> Because if there's an index, the database needs to update the
>>>>>>>>>> index every time there is new document inserted.
>>>>>>>>>> Is it possible, and i'm just wondering here, that PostgreSQL is
>>>>>>>>>> one of the causes of the batch being slow?
>>>>>>>>>> If not do you have any more information on why is not?
>>>>>>>>>> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>>>>>>>>>>> Good afternoon,
>>>>>>>>>>> I'am using MongoDB with 350 000 documents and php. The problem
>>>>>>>>>>> is the php reads documents very slowly .
>>>>>>>>>>> When I'm updating documents I drop the database and I insert the
>>>>>>>>>>> documents : during this processus the inserts are very long .
>>>>>>>>>>> I don't understand, I putted indexes .
>>>>>>>>>>> I show you a piece of my php code when I updating documents :
>>>>>>>>>>> $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x"));
>>>>>>>>>>> print($cursor->count()); // I display the number of documents
>>>>>>>>>>> foreach($cursor as $obj){
>>>>>>>>>>> ///I display the results of document
>>>>>>>>>>> }
>>>>>>>>>>> The tags field containts array keywords .
>>>>>>>>>>> What should I do to resolve this problem ?
>>>>>>>>>>> I checked the RAM (6 Go of physical RAM and 4 Go of available
>>>>>>>>>>> memory) .
>>>>>>>>>>> How can I check the cause of this slow reads and inserts ?
>>>>>>>>>>> I there is something to configure in mongodb ?
>>>>>>>>>>> Best regards .
>>>>>>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "mongodb-user" group.
>>>> To post to this group, send email to mongod...@googlegroups.com
>>>> To unsubscribe from this group, send email to
>>>> mongodb-user...@**googlegroups.com
>>>> See also the IRC channel -- freenode.net#mongodb
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "mongodb-user" group.
> Basically I understand what your trying to do, essentially an FTS. Problem
> is the infixing on your fields is 2 characters min so "win 2008 Server R
> Data" won't match without regex. I strongely suggest you either deal with
> out regex or you split up your words further, but then they could lose
> their meaning and return superflious amount of documents.
> On 10 September 2012 20:50, Sam Millman <sam.mill...@gmail.com> wrote:
>> If it is an array of words then you don't need the regex, try taking that
>> out.
>> On 10 September 2012 20:44, marcandre <malegr...@gmail.com> wrote:
>>> In this code I am trying is to research only documents that have all
>>> keywords asked by the client,
>>> For example a user who is looking for documents, when he types "windows
>>> 2008 Server R2 Datacenter" or "win 2008 Server R Data" the research engin
>>> have to
>>> display documents that contains the following keywords : array(0 =>
>>> windows, 2008, Server, R2, Datacenter) contained in the "tags" field (It
>>> is an array)
>>> Le lundi 10 septembre 2012 21:14:11 UTC+2, Sammaye a écrit :
>>>> Non-prefixed regexes do not use indexes would be one of your problems:
>>>> On 10 September 2012 20:10, marcandre <male...@gmail.com> wrote:
>>>>> Thank you very much for these informations,
>>>>> But, how can I get a BtreeCursor with ensureIndex() function ?
>>>>> Whitch arguments can I put in this function, I know that I have to
>>>>> give the field name in the first argument .
>>>>> Le lundi 10 septembre 2012 18:01:33 UTC+2, Gianfranco a écrit :
>>>>>> Yes, as Gelin said.
>>>>>> That query is not using an index, that's why is taking longer, going
>>>>>> through the entire collection.
>>>>>> Make sure you ensureIndex() on the correct fields.
>>>>>> Then try doing an explain again to check if it worked
>>>>>> On Monday, September 10, 2012 4:52:28 PM UTC+1, gelin yan wrote:
>>>>>>>> I am limiting the find to avoid display every documents in the same
>>>>>>>> page .
>>>>>>> Hi
>>>>>>> "BasicCursor" implies your index didn't work for your query.
>>>>>>>> Le lundi 10 septembre 2012 17:31:40 UTC+2, Gianfranco a écrit :
>>>>>>>>> If you run explain() on the cursor you can see why is taking that
>>>>>>>>> long.
>>>>>>>>> var_dump($cursor->explain());
>>>>>>>>> Do that on one and see if it's using an index (BtreeCursor)
>>>>>>>>> Another problem could be that you are limiting the find() results
>>>>>>>>> to 30 and then doing a skip.
>>>>>>>>> This is not every efficient, and I don't understand from your code
>>>>>>>>> exactly why are you doing that.
>>>>>>>>> You can also try to increase the timeout of the cursor and try if
>>>>>>>>> that helps
>>>>>>>>> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>>>>>>>>>> I don't think that Postgres causes the bach being slow, because
>>>>>>>>>> when I use MongoDB as a reseach engin to research documents by keywords ,
>>>>>>>>>> my reseach engin is very slow or ends with an error of timeout :
>>>>>>>>>> *Fatal error: Uncaught exception 'MongoCursorTimeoutException'
>>>>>>>>>> with message 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'
>>>>>>>>>> * .
>>>>>>>>>> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>>>>>>>>>>> As you did correctly, if this is not a live production database,
>>>>>>>>>>> you can ensureIndex() after you finish the batch.
>>>>>>>>>>> Because if there's an index, the database needs to update the
>>>>>>>>>>> index every time there is new document inserted.
>>>>>>>>>>> Is it possible, and i'm just wondering here, that PostgreSQL is
>>>>>>>>>>> one of the causes of the batch being slow?
>>>>>>>>>>> If not do you have any more information on why is not?
>>>>>>>>>>> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>>>>>>>>>>>> Good afternoon,
>>>>>>>>>>>> I'am using MongoDB with 350 000 documents and php. The problem
>>>>>>>>>>>> is the php reads documents very slowly .
>>>>>>>>>>>> When I'm updating documents I drop the database and I insert
>>>>>>>>>>>> the documents : during this processus the inserts are very long .
>>>>>>>>>>>> I don't understand, I putted indexes .
>>>>>>>>>>>> I show you a piece of my php code when I updating documents :
>>>>>>>>>>>> $cnx_mongo = new Mongo("127.0.0.1", array("persist" => "x"));
For this moment my code look for one key word . I use research by keyword prefix like for example /^windows/ . But when I type the word (windows for example), the first time the web page is very slow (It take 1 or 2 minutes to display results), and the second time the web page responses very quikly (less than 1 second) .
Thank you very much
Le lundi 10 septembre 2012 22:03:35 UTC+2, Sammaye a écrit :
> Though thinking twice here, you can prefix since win would match windows > with /^win/ and r would match r2 with /^r/. That might work.
> On 10 September 2012 20:52, Sam Millman <sam.m...@gmail.com <javascript:>>wrote:
>> Ok my last message was written a bit quickly.
>> Basically I understand what your trying to do, essentially an FTS. >> Problem is the infixing on your fields is 2 characters min so "win 2008 >> Server R Data" won't match without regex. I strongely suggest you either >> deal with out regex or you split up your words further, but then they could >> lose their meaning and return superflious amount of documents.
>> On 10 September 2012 20:50, Sam Millman <sam.m...@gmail.com <javascript:>
>> > wrote:
>>> If it is an array of words then you don't need the regex, try taking >>> that out.
>>> On 10 September 2012 20:44, marcandre <male...@gmail.com <javascript:>>wrote:
>>>> In this code I am trying is to research only documents that have all >>>> keywords asked by the client,
>>>> For example a user who is looking for documents, when he types "windows >>>> 2008 Server R2 Datacenter" or "win 2008 Server R Data" the research engin >>>> have to
>>>> display documents that contains the following keywords : array(0 => >>>> windows, 2008, Server, R2, Datacenter) contained in the "tags" field (It >>>> is an array)
>>>> Le lundi 10 septembre 2012 21:14:11 UTC+2, Sammaye a écrit :
>>>>> Non-prefixed regexes do not use indexes would be one of your problems:
>>>>> On 10 September 2012 20:10, marcandre <male...@gmail.com> wrote:
>>>>>> Thank you very much for these informations,
>>>>>> But, how can I get a BtreeCursor with ensureIndex() function ?
>>>>>> Whitch arguments can I put in this function, I know that I have to >>>>>> give the field name in the first argument .
>>>>>> Le lundi 10 septembre 2012 18:01:33 UTC+2, Gianfranco a écrit :
>>>>>>> Yes, as Gelin said.
>>>>>>> That query is not using an index, that's why is taking longer, going >>>>>>> through the entire collection.
>>>>>>> Make sure you ensureIndex() on the correct fields.
>>>>>>> Then try doing an explain again to check if it worked
>>>>>>> On Monday, September 10, 2012 4:52:28 PM UTC+1, gelin yan wrote:
>>>>>>>>> I am limiting the find to avoid display every documents in the >>>>>>>>> same page .
>>>>>>>> Hi >>>>>>>> "BasicCursor" implies your index didn't work for your query.
>>>>>>>>> Le lundi 10 septembre 2012 17:31:40 UTC+2, Gianfranco a écrit :
>>>>>>>>>> If you run explain() on the cursor you can see why is taking that >>>>>>>>>> long.
>>>>>>>>>> var_dump($cursor->explain());
>>>>>>>>>> Do that on one and see if it's using an index (BtreeCursor)
>>>>>>>>>> Another problem could be that you are limiting the find() results >>>>>>>>>> to 30 and then doing a skip.
>>>>>>>>>> This is not every efficient, and I don't understand from your >>>>>>>>>> code exactly why are you doing that.
>>>>>>>>>> You can also try to increase the timeout of the cursor and try if >>>>>>>>>> that helps
>>>>>>>>>> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>>>>>>>>>>> I don't think that Postgres causes the bach being slow, because >>>>>>>>>>> when I use MongoDB as a reseach engin to research documents by keywords ,
>>>>>>>>>>> my reseach engin is very slow or ends with an error of timeout : >>>>>>>>>>> *Fatal error: Uncaught exception 'MongoCursorTimeoutException' >>>>>>>>>>> with message 'cursor timed out (timeout: 30000, time left: 0:0, status: 0)'
>>>>>>>>>>> * .
>>>>>>>>>>> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>>>>>>>>>>>> As you did correctly, if this is not a live production >>>>>>>>>>>> database, you can ensureIndex() after you finish the batch.
>>>>>>>>>>>> Because if there's an index, the database needs to update the >>>>>>>>>>>> index every time there is new document inserted.
>>>>>>>>>>>> Is it possible, and i'm just wondering here, that PostgreSQL is >>>>>>>>>>>> one of the causes of the batch being slow?
>>>>>>>>>>>> If not do you have any more information on why is not?
>>>>>>>>>>>> On Monday, September 10, 2012 1:50:17 PM UTC+1, marcandre wrote:
>>>>>>>>>>>>> Good afternoon,
>>>>>>>>>>>>> I'am using MongoDB with 350 000 documents and php. The problem >>>>>>>>>>>>> is the php reads documents very slowly .
>>>>>>>>>>>>> When I'm updating documents I drop the database and I insert >>>>>>>>>>>>> the documents :
> For this moment my code look for one key word . I use research by keyword > prefix like for example /^windows/ . But when I type the word (windows for > example), the first time the web page is very slow (It take 1 or 2 > minutes to display results), and the second time the web page responses > very quikly (less than 1 second) .
> Thank you very much
> Le lundi 10 septembre 2012 22:03:35 UTC+2, Sammaye a écrit :
>> Though thinking twice here, you can prefix since win would match windows >> with /^win/ and r would match r2 with /^r/. That might work.
>> On 10 September 2012 20:52, Sam Millman <sam.m...@gmail.com> wrote:
>>> Ok my last message was written a bit quickly.
>>> Basically I understand what your trying to do, essentially an FTS. >>> Problem is the infixing on your fields is 2 characters min so "win 2008 >>> Server R Data" won't match without regex. I strongely suggest you either >>> deal with out regex or you split up your words further, but then they could >>> lose their meaning and return superflious amount of documents.
>>> On 10 September 2012 20:50, Sam Millman <sam.m...@gmail.com> wrote:
>>>> If it is an array of words then you don't need the regex, try taking >>>> that out.
>>>> On 10 September 2012 20:44, marcandre <male...@gmail.com> wrote:
>>>>> In this code I am trying is to research only documents that have all >>>>> keywords asked by the client,
>>>>> For example a user who is looking for documents, when he types >>>>> "windows 2008 Server R2 Datacenter" or "win 2008 Server R >>>>> Data" the research engin have to
>>>>> display documents that contains the following keywords : array(0 => >>>>> windows, 2008, Server, R2, Datacenter) contained in the "tags" field (It >>>>> is an array)
>>>>> Le lundi 10 septembre 2012 21:14:11 UTC+2, Sammaye a écrit :
>>>>>> Non-prefixed regexes do not use indexes would be one of your problems:
>>>>>> On 10 September 2012 20:10, marcandre <male...@gmail.com> wrote:
>>>>>>> Thank you very much for these informations,
>>>>>>> But, how can I get a BtreeCursor with ensureIndex() function ?
>>>>>>> Whitch arguments can I put in this function, I know that I have to >>>>>>> give the field name in the first argument .
>>>>>>> Le lundi 10 septembre 2012 18:01:33 UTC+2, Gianfranco a écrit :
>>>>>>>> Yes, as Gelin said.
>>>>>>>> That query is not using an index, that's why is taking longer, >>>>>>>> going through the entire collection.
>>>>>>>> Make sure you ensureIndex() on the correct fields.
>>>>>>>> Then try doing an explain again to check if it worked
>>>>>>>> On Monday, September 10, 2012 4:52:28 PM UTC+1, gelin yan wrote:
>>>>>>>>>> I am limiting the find to avoid display every documents in the >>>>>>>>>> same page .
>>>>>>>>> Hi >>>>>>>>> "BasicCursor" implies your index didn't work for your query.
>>>>>>>>>> Le lundi 10 septembre 2012 17:31:40 UTC+2, Gianfranco a écrit :
>>>>>>>>>>> If you run explain() on the cursor you can see why is taking >>>>>>>>>>> that long.
>>>>>>>>>>> var_dump($cursor->explain());
>>>>>>>>>>> Do that on one and see if it's using an index (BtreeCursor)
>>>>>>>>>>> Another problem could be that you are limiting the find() >>>>>>>>>>> results to 30 and then doing a skip.
>>>>>>>>>>> This is not every efficient, and I don't understand from your >>>>>>>>>>> code exactly why are you doing that.
>>>>>>>>>>> You can also try to increase the timeout of the cursor and try >>>>>>>>>>> if that helps
>>>>>>>>>>> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>>>>>>>>>>>> I don't think that Postgres causes the bach being slow, because >>>>>>>>>>>> when I use MongoDB as a reseach engin to research documents by keywords ,
>>>>>>>>>>>> my reseach engin is very slow or ends with an error of timeout >>>>>>>>>>>> : *Fatal error: Uncaught exception >>>>>>>>>>>> 'MongoCursorTimeoutException' with message 'cursor timed out (timeout: >>>>>>>>>>>> 30000, time left: 0:0, status: 0)'* .
>>>>>>>>>>>> Le lundi 10 septembre 2012 16:42:35 UTC+2, Gianfranco a écrit :
>>>>>>>>>>>>> As you did correctly, if this is not a live production >>>>>>>>>>>>> database, you can ensureIndex() after you finish the batch.
>>>>>>>>>>>>> Because if there's an index, the database needs to update the >>>>>>>>>>>>> index every time there is new document inserted.
>>>>>>>>>>>>> Is it possible, and i'm just wondering here, that PostgreSQL >>>>>>>>>>>>> is one of the causes of the batch being slow?
>>>>>>>>>>>>> If not do you have any more information on why is not?
>> For this moment my code look for one key word . I use research by keyword
>> prefix like for example /^windows/ . But when I type the word (windows for
>> example), the first time the web page is very slow (It take 1 or 2
>> minutes to display results), and the second time the web page responses
>> very quikly (less than 1 second) .
>> Thank you very much
>> Le lundi 10 septembre 2012 22:03:35 UTC+2, Sammaye a écrit :
>>> Though thinking twice here, you can prefix since win would match windows
>>> with /^win/ and r would match r2 with /^r/. That might work.
>>> On 10 September 2012 20:52, Sam Millman <sam.m...@gmail.com> wrote:
>>>> Ok my last message was written a bit quickly.
>>>> Basically I understand what your trying to do, essentially an FTS.
>>>> Problem is the infixing on your fields is 2 characters min so "win 2008
>>>> Server R Data" won't match without regex. I strongely suggest you either
>>>> deal with out regex or you split up your words further, but then they could
>>>> lose their meaning and return superflious amount of documents.
>>>> On 10 September 2012 20:50, Sam Millman <sam.m...@gmail.com> wrote:
>>>>> If it is an array of words then you don't need the regex, try taking
>>>>> that out.
>>>>> On 10 September 2012 20:44, marcandre <male...@gmail.com> wrote:
>>>>>> In this code I am trying is to research only documents that have all
>>>>>> keywords asked by the client,
>>>>>> For example a user who is looking for documents, when he types
>>>>>> "windows 2008 Server R2 Datacenter" or "win 2008 Server R
>>>>>> Data" the research engin have to
>>>>>> display documents that contains the following keywords : array(0 =>
>>>>>> windows, 2008, Server, R2, Datacenter) contained in the "tags" field (It
>>>>>> is an array)
>>>>>> Le lundi 10 septembre 2012 21:14:11 UTC+2, Sammaye a écrit :
>>>>>>> Non-prefixed regexes do not use indexes would be one of your
>>>>>>> problems:
>>>>>>> On 10 September 2012 20:10, marcandre <male...@gmail.com> wrote:
>>>>>>>> Thank you very much for these informations,
>>>>>>>> But, how can I get a BtreeCursor with ensureIndex() function ?
>>>>>>>> Whitch arguments can I put in this function, I know that I have to
>>>>>>>> give the field name in the first argument .
>>>>>>>> Le lundi 10 septembre 2012 18:01:33 UTC+2, Gianfranco a écrit :
>>>>>>>>> Yes, as Gelin said.
>>>>>>>>> That query is not using an index, that's why is taking longer,
>>>>>>>>> going through the entire collection.
>>>>>>>>> Make sure you ensureIndex() on the correct fields.
>>>>>>>>> Then try doing an explain again to check if it worked
>>>>>>>>> On Monday, September 10, 2012 4:52:28 PM UTC+1, gelin yan wrote:
>>>>>>>>>>> I am limiting the find to avoid display every documents in the
>>>>>>>>>>> same page .
>>>>>>>>>> Hi
>>>>>>>>>> "BasicCursor" implies your index didn't work for your query.
>>>>>>>>>>> Le lundi 10 septembre 2012 17:31:40 UTC+2, Gianfranco a écrit :
>>>>>>>>>>>> If you run explain() on the cursor you can see why is taking
>>>>>>>>>>>> that long.
>>>>>>>>>>>> var_dump($cursor->explain());
>>>>>>>>>>>> Do that on one and see if it's using an index (BtreeCursor)
>>>>>>>>>>>> Another problem could be that you are limiting the find()
>>>>>>>>>>>> results to 30 and then doing a skip.
>>>>>>>>>>>> This is not every efficient, and I don't understand from your
>>>>>>>>>>>> code exactly why are you doing that.
>>>>>>>>>>>> You can also try to increase the timeout of the cursor and try
>>>>>>>>>>>> if that helps
>>>>>>>>>>>> On Monday, September 10, 2012 4:07:30 PM UTC+1, marcandre wrote:
>>>>>>>>>>>>> I don't think that Postgres causes the bach being slow,
>>>>>>>>>>>>> because when I use MongoDB as a reseach engin to research documents by
>>>>>>>>>>>>> keywords ,
>>>>>>>>>>>>> my reseach engin is very slow or ends with an error of timeout
>>>>>>>>>>>>> : *Fatal error: Uncaught exception
>>>>>>>>>>>>> 'MongoCursorTimeoutException' with message 'cursor timed out (timeout:
>>>>>>>>>>>>> 30000, time left: 0:0, status: 0)'* .
>>>>>>>>>>>>> This my code for research douments :
>>> For this moment my code look for one key word . I use research by >>> keyword prefix like for example /^windows/ . But when I type the word >>> (windows for example), the first time the web page is very slow (It take 1 >>> or 2 minutes to display results), and the second time the web page >>> responses very quikly (less than 1 second) .
>>> Thank you very much
>>> Le lundi 10 septembre 2012 22:03:35 UTC+2, Sammaye a écrit :
>>>> Though thinking twice here, you can prefix since win would match >>>> windows with /^win/ and r would match r2 with /^r/. That might work.
>>>> On 10 September 2012 20:52, Sam Millman <sam.m...@gmail.com> wrote:
>>>>> Ok my last message was written a bit quickly.
>>>>> Basically I understand what your trying to do, essentially an FTS. >>>>> Problem is the infixing on your fields is 2 characters min so "win 2008 >>>>> Server R Data" won't match without regex. I strongely suggest you either >>>>> deal with out regex or you split up your words further, but then they could >>>>> lose their meaning and return superflious amount of documents.
>>>>> On 10 September 2012 20:50, Sam Millman <sam.m...@gmail.com> wrote:
>>>>>> If it is an array of words then you don't need the regex, try taking >>>>>> that out.
>>>>>> On 10 September 2012 20:44, marcandre <male...@gmail.com> wrote:
>>>>>>> In this code I am trying is to research only documents that have all >>>>>>> keywords asked by the client,
>>>>>>> For example a user who is looking for documents, when he types >>>>>>> "windows 2008 Server R2 Datacenter" or "win 2008 Server R >>>>>>> Data" the research engin have to
>>>>>>> display documents that contains the following keywords : array(0 => >>>>>>> windows, 2008, Server, R2, Datacenter) contained in the "tags" field (It >>>>>>> is an array)
>>>>>>> Le lundi 10 septembre 2012 21:14:11 UTC+2, Sammaye a écrit :
>>>>>>>> Non-prefixed regexes do not use indexes would be one of your >>>>>>>> problems:
>>>>>>>> On 10 September 2012 20:10, marcandre <male...@gmail.com> wrote:
>>>>>>>>> Thank you very much for these informations,
>>>>>>>>> But, how can I get a BtreeCursor with ensureIndex() function ?
>>>>>>>>> Whitch arguments can I put in this function, I know that I have to >>>>>>>>> give the field name in the first argument .
>>>>>>>>> Le lundi 10 septembre 2012 18:01:33 UTC+2, Gianfranco a écrit :
>>>>>>>>>> Yes, as Gelin said.
>>>>>>>>>> That query is not using an index, that's why is taking longer, >>>>>>>>>> going through the entire collection.
>>>>>>>>>> Make sure you ensureIndex() on the correct fields.
>>>>>>>>>> Then try doing an explain again to check if it worked
>>>>>>>>>> On Monday, September 10, 2012 4:52:28 PM UTC+1, gelin yan wrote:
>>>> For this moment my code look for one key word . I use research by
>>>> keyword prefix like for example /^windows/ . But when I type the word
>>>> (windows for example), the first time the web page is very slow (It take 1
>>>> or 2 minutes to display results), and the second time the web page
>>>> responses very quikly (less than 1 second) .
>>>> Thank you very much
>>>> Le lundi 10 septembre 2012 22:03:35 UTC+2, Sammaye a écrit :
>>>>> Though thinking twice here, you can prefix since win would match
>>>>> windows with /^win/ and r would match r2 with /^r/. That might work.
>>>>> On 10 September 2012 20:52, Sam Millman <sam.m...@gmail.com> wrote:
>>>>>> Ok my last message was written a bit quickly.
>>>>>> Basically I understand what your trying to do, essentially an FTS.
>>>>>> Problem is the infixing on your fields is 2 characters min so "win 2008
>>>>>> Server R Data" won't match without regex. I strongely suggest you either
>>>>>> deal with out regex or you split up your words further, but then they could
>>>>>> lose their meaning and return superflious amount of documents.
>>>>>> On 10 September 2012 20:50, Sam Millman <sam.m...@gmail.com> wrote:
>>>>>>> If it is an array of words then you don't need the regex, try taking
>>>>>>> that out.
>>>>>>> On 10 September 2012 20:44, marcandre <male...@gmail.com> wrote:
>>>>>>>> In this code I am trying is to research only documents that have
>>>>>>>> all keywords asked by the client,
>>>>>>>> For example a user who is looking for documents, when he types
>>>>>>>> "windows 2008 Server R2 Datacenter" or "win 2008 Server R
>>>>>>>> Data" the research engin have to
>>>>>>>> display documents that contains the following keywords : array(0 =>
>>>>>>>> windows, 2008, Server, R2, Datacenter) contained in the "tags" field (It
>>>>>>>> is an array)
>>>>>>>> Le lundi 10 septembre 2012 21:14:11 UTC+2, Sammaye a écrit :
>>>>>>>>> Non-prefixed regexes do not use indexes would be one of your
>>>>>>>>> problems:
>>>>>>>>> On 10 September 2012 20:10, marcandre <male...@gmail.com> wrote:
>>>>>>>>>> Thank you very much for these informations,
>>>>>>>>>> But, how can I get a BtreeCursor with ensureIndex() function ?
>>>>>>>>>> Whitch arguments can I put in this function, I know that I have
>>>>>>>>>> to give the field name in the first argument .
>>>>>>>>>> Le lundi 10 septembre 2012 18:01:33 UTC+2, Gianfranco a écrit :
>>>>>>>>>>> Yes, as Gelin said.
>>>>>>>>>>> That query is not using an index, that's why is taking longer,
>>>>>>>>>>> going through the entire collection.
>>>>>>>>>>> Make sure you ensureIndex() on the correct fields.
>>>>>>>>>>> Then try doing an explain again to check if it worked
>>>>>>>>>>> On Monday, September 10, 2012 4:52:28 PM UTC+1, gelin yan wrote:
>>>>> For this moment my code look for one key word . I use research by >>>>> keyword prefix like for example /^windows/ . But when I type the word >>>>> (windows for example), the first time the web page is very slow (It take 1 >>>>> or 2 minutes to display results), and the second time the web page >>>>> responses very quikly (less than 1 second) .
>>>>> Thank you very much
>>>>> Le lundi 10 septembre 2012 22:03:35 UTC+2, Sammaye a écrit :
>>>>>> Though thinking twice here, you can prefix since win would match >>>>>> windows with /^win/ and r would match r2 with /^r/. That might work.
>>>>>> On 10 September 2012 20:52, Sam Millman <sam.m...@gmail.com> wrote:
>>>>>>> Ok my last message was written a bit quickly.
>>>>>>> Basically I understand what your trying to do, essentially an FTS. >>>>>>> Problem is the infixing on your fields is 2 characters min so "win 2008 >>>>>>> Server R Data" won't match without regex. I strongely suggest you either >>>>>>> deal with out regex or you split up your words further, but then they could >>>>>>> lose their meaning and return superflious amount of documents.
>>>>>>> On 10 September 2012 20:50, Sam Millman <sam.m...@gmail.com> wrote:
>>>>>>>> If it is an array of words then you don't need the regex, try >>>>>>>> taking that out.
>>>>>>>> On 10 September 2012 20:44, marcandre <male...@gmail.com> wrote:
>>>>>>>>> In this code I am trying is to research only documents that have >>>>>>>>> all keywords asked by the client,
>>>>>>>>> For example a user who is looking for documents, when he types >>>>>>>>> "windows 2008 Server R2 Datacenter" or "win 2008 Server R >>>>>>>>> Data" the research engin have to
>>>>>>>>> display documents that contains the following keywords : array(0 >>>>>>>>> => windows, 2008, Server, R2, Datacenter) contained in the "tags" field >>>>>>>>> (It is an array)
>>>>>>>>> Le lundi 10 septembre 2012 21:14:11 UTC+2, Sammaye a écrit :
>>>>>>>>>> Non-prefixed regexes do not use indexes would be one of your >>>>>>>>>> problems:
>>>>>> For this moment my code look for one key word . I use research by >>>>>> keyword prefix like for example /^windows/ . But when I type the word >>>>>> (windows for example), the first time the web page is very slow (It take 1 >>>>>> or 2 minutes to display results), and the second time the web page >>>>>> responses very quikly (less than 1 second) .
>>>>>> Thank you very much
>>>>>> Le lundi 10 septembre 2012 22:03:35 UTC+2, Sammaye a écrit :
>>>>>>> Though thinking twice here, you can prefix since win would match >>>>>>> windows with /^win/ and r would match r2 with /^r/. That might work.
>>>>>>> On 10 September 2012 20:52, Sam Millman <sam.m...@gmail.com> wrote:
>>>>>>>> Ok my last message was written a bit quickly.
>>>>>>>> Basically I understand what your trying to do, essentially an FTS. >>>>>>>> Problem is the infixing on your fields is 2 characters min so "win 2008 >>>>>>>> Server R Data" won't match without regex. I strongely suggest you either >>>>>>>> deal with out regex or you split up your words further, but then they could >>>>>>>> lose their meaning and return superflious amount of documents.
>>>>>>>> On 10 September 2012 20:50, Sam Millman <sam.m...@gmail.com> wrote:
>>>>>>>>> If it is an array of words then you don't need the regex, try >>>>>>>>> taking that out.
>>>>>>>>> On 10 September 2012 20:44, marcandre <male...@gmail.com> wrote:
>>>>>>>>>> In this code I am trying is to research only documents that have >>>>>>>>>> all keywords asked by the client,
>>>>>>>>>> For example a user who is looking for documents, when he types >>>>>>>>>> "windows 2008 Server R2 Datacenter" or "win 2008 Server R >>>>>>>>>> Data" the research engin have to
>>>>>>>>>> display documents that contains the following keywords : array(0 >>>>>>>>>> => windows, 2008, Server, R2, Datacenter) contained in the "tags" field >>>>>>>>>> (It is an array)
>>>>>>>>>> Le lundi 10 septembre 2012 21:14:11 UTC+2, Sammaye a écrit :
>>>>>>>>>>> Non-prefixed regexes do not use indexes would be one of your >>>>>>>>>>> problems:
I come back to you and I'm looking for a solution for my query slowness from php again .
Is there someone can suggest me something about this problem ?
Best regards .
Le mardi 11 septembre 2012 21:50:06 UTC+2, marcandre a écrit :
