Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 52FD21337A67 for ; Sat, 30 Apr 2011 19:29:48 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 46865-06 for ; Sat, 30 Apr 2011 22:29:31 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wy0-f174.google.com (mail-wy0-f174.google.com [74.125.82.174]) by mail.postgresql.org (Postfix) with ESMTP id 4EB781337990 for ; Sat, 30 Apr 2011 19:29:29 -0300 (ADT) Received: by wya21 with SMTP id 21so3520869wya.19 for ; Sat, 30 Apr 2011 15:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=M2deR16jxXsq3PNnNzmWc45CBoh0cN2zgezdJXRLyik=; b=Bfyub8jHhB3JXo8lRrvbLJ+t30R4A1UopNnEA7PgLsWPoVaJpk6xYoimq3kUez9d2w t2KCLkNlEwikAbGJq71E76HZewuAWGHx0JJQZ/82sf0W18H8YNz5vxL0vXmOyoK8wJN1 i9pdd7lc+grpvfPSLU0NDiAUq/j3RwHxxYbeM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=LvKG4dubwy0Kh4Gf2EdTsy6gTWDL0Org7r0jcZy7ZHrlXuCaqNzFYeTy8S6fe+TzBt FdsvORpQPUad7DykSrG6XtLyrK/I/HHw+0DBcyK7SYA3puNtIGdP6Z83/6ZfrvNmnLIi oUi8dndWAActuOYOcRuYAPv3tHqmc2ADLWY4M= Received: by 10.227.57.83 with SMTP id b19mr2455010wbh.15.1304202569021; Sat, 30 Apr 2011 15:29:29 -0700 (PDT) Received: from [192.168.0.196] ([95.60.213.7]) by mx.google.com with ESMTPS id h11sm2494950wbc.9.2011.04.30.15.29.26 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Apr 2011 15:29:28 -0700 (PDT) Subject: Re: stored proc and inserting hundreds of thousands of rows Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Reymont In-Reply-To: Date: Sat, 30 Apr 2011 23:29:25 +0100 Cc: Kevin Grittner , "pgsql-performance@postgresql.org" Content-Transfer-Encoding: quoted-printable Message-Id: <76A45DA2-2AC3-4F58-933B-D4DCD61B8DCE@gmail.com> References: <4DBC004C020000250003D099@gw.wicourts.gov> <4881277622113933088@unknownmsgid> <4DBC0D7C020000250003D09E@gw.wicourts.gov> To: Jeff Janes X-Mailer: Apple Mail (2.1084) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.03 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=1.553, FREEMAIL_FROM=0.001, RFC_ABUSE_POST=0.001, SARE_MILLIONSOF=0.315 X-Spam-Level: X-Archive-Number: 201104/445 X-Sequence-Number: 43507 On Apr 30, 2011, at 11:11 PM, Jeff Janes wrote: > But what exactly are you inserting? The queries you reported below > are not the same as the ones you originally described. I posted the wrong query initially. The only difference is in the table = that holds the probability array. I'm inserting document id and ad id pairs to show that this ad is not = linked to this document. The mapping table has a primary key on the = serial document id. > In particular, they do not seem to use the "threshold" parameter that > the original ones did, whose job is presumably to cut the 2 million > down to a much smaller number that meet the threshold. But how much > smaller is that number? The 5 minutes is with a threshold large enough to be irrelevant. I would = like to optimize the process before I apply the threshold to cut down = the number of rows. > It looks like "WHERE tab.distance <=3D 50.0;" is not accomplishing > anything. Are you sure the parameter shouldn't be <=3D0.50 instead? No, ignore the threshold for now. > Also, you previously said you didn't mind of this process took a > couple minutes, as long as it didn't interfere with other things going > on in the database. So you probably need to describe what those other > things going on in the database are. Those other things are ad serving which boils down to a lookup of ad ids = linked to the document.=20 This is a lookup from the mapping table using the primary key that goes = on at the same time as a large number of mappings are being = inserted into the same table. Documents are uploaded into the system at a rate of 10k per day, once = every couple of seconds. I wish I could get rid of storing the = mapping as that table is gonna grow absolutely huge when each new ad = matches tens or hundreds of thousands of documents.=20 I don't think I can do the matching when serving an ad, though, as I = will still need to scan millions of probability vectors (one per doc) to = calculate the distance between current document and existing ads. Then again, the number of ads in the system will always be a fraction of = the number of documents so, perhaps, the matching of document to ads can = be done at runtime. > Also, you might have a data correctness problem. If the plan is to > scan new ads against all docs, and new docs against all ads; That's basically it.=20 As new ads are entered, they need to be matched with existing documents.=20= As new documents are entered, they need to be matched with existing ads.=20= Both ads and docs are represented by probability vectors of 150 floats = so it's the same distance calculation. > then if new rows are added to each table during overlapping = transaction, the > new ads against new docs comparison will not actually happen. You > will probably need to add manual locking to get around this problem. I'll ponder this, thanks for pointing it out! = --------------------------------------------------------------------------= - for hire: mac osx device driver ninja, kernel extensions and usb = drivers = ---------------------+------------+---------------------------------------= http://wagerlabs.com | @wagerlabs | = http://www.linkedin.com/in/joelreymont = ---------------------+------------+---------------------------------------=