Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 6B61D9F9D80; Sat, 25 Aug 2007 15:18:41 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 63651-01; Sat, 25 Aug 2007 15:18:33 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from lists.commandprompt.com (host-254.commandprompt.net [207.173.203.254]) by postgresql.org (Postfix) with ESMTP id E17209F9B22; Sat, 25 Aug 2007 15:18:34 -0300 (ADT) Received: from [192.168.1.50] (or-67-76-146-141.sta.embarqhsd.net [67.76.146.141]) (authenticated bits=0) by lists.commandprompt.com (8.13.7/8.13.6) with ESMTP id l7PIIRlw001468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 11:18:28 -0700 Message-ID: <46D07279.7010603@commandprompt.com> Date: Sat, 25 Aug 2007 11:18:33 -0700 From: "Joshua D. Drake" User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Benjamin Arai CC: Brandon Shalton , PostgreSQL , pgsql-performance@postgresql.org Subject: Re: [PERFORM] Partioning tsearch2 a table into chunks and accessing via views References: <3147EF26-2649-4FDF-BD86-2DB0AF8460FC@benjaminarai.com> <0be901c7e6cb$a2b13320$c901a8c0@blaptop> <46CF85EE.5040805@commandprompt.com> <46D0564A.7030405@commandprompt.com> <29A8F3CE-03F9-4E92-A354-6F4FC3C810F4@benjaminarai.com> In-Reply-To: <29A8F3CE-03F9-4E92-A354-6F4FC3C810F4@benjaminarai.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.1/4054/Fri Aug 24 09:55:59 2007 on projects.commandprompt.com X-Virus-Status: Clean X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.6 (lists.commandprompt.com [192.168.2.159]); Sat, 25 Aug 2007 11:18:28 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200708/1579 X-Sequence-Number: 119428 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benjamin Arai wrote: > As stated in the previous email if I use partitioning then queries will > be executed sequentially - i.e., instead of log(n) it would be (# > partitions) * log(n). Right? The planner will consider every relevant partition during the execution. Which may be a performance hit, it may not be. It depends on many factors. In general however, partitioning when done correctly is a performance benefit and a maintenance benefit. Sincerely, Joshua D. Drake > > Benjamin > > On Aug 25, 2007, at 9:18 AM, Joshua D. Drake wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 > >> Benjamin Arai wrote: >>> This kind of disappointing, I was hoping there was more that could be >>> done. >>> >>> There has to be another way to do incremental indexing without loosing >>> that much performance. > >> What makes you think you are loosing performance by using partitioning? > >> Joshua D. Drake > >>> >>> Benjamin >>> >>> On Aug 24, 2007, at 6:29 PM, Joshua D. Drake wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>> >>>> Brandon Shalton wrote: >>>>> Benjamin, >>>>> >>>>> >>>>>> >>>>>> In order to avoid the re-indexing I was thinking of instead creating >>>>>> a new >>>>>> table each month (building its indexes and etc) and accessing them >>>>>> all >>>>>> through a view. This way I only have to index the new data each >>>>>> month. >>>>>> >>>>> >>>>> Take a look at bizgres.org (based on postgres). >>>>> >>>>> They have a parent-child structure. >>>>> >>>>> The way i use it, is I have about 30M records a day that are inserted >>>>> into the database. >>>>> >>>>> Each day is a "child" table to the "parent". >>>>> >>>>> so example: >>>>> >>>>> the parent table is called "logfile" >>>>> >>>>> each day, is a child, with the structure like "logfile_YYMMDD" >>>>> >>>>> the "child" inherits the table structure of the parent, such that you >>>>> could query the child table name directly, or you run the query >>>>> against >>>>> the parent (ie. logfile table) and get all the data. >>>>> >>>>> the indexes are done on a per table basis, so new data that comes >>>>> in, is >>>>> a lesser amount, and doesn't require re-indexing. >>> >>> >>>> PostgreSQL can do all of this too. >>> >>>> Sincerely, >>> >>>> Joshua D. Drake >>> >>>>> >>>>> >>>>> example: >>>>> >>>>> select * from logfile_070825 where datafield = 'foo' >>>>> >>>>> if i knew i wanted to specifically go into that child, or: >>>>> >>>>> select * from logfile where datafield = 'foo' >>>>> >>>>> and all child tables are searched and results merged. You can perform >>>>> any kind of sql query and field structures are you normally do. >>>>> >>>>> the downside is that the queries are run sequentially. >>>>> >>>>> so if you had 100 child tables, each table is queried via indexes, >>>>> then >>>>> results are merged. >>>>> >>>>> but, this approach does allow me to dump alot of data in, without >>>>> having >>>>> the re-indexing issues you are facing. >>>>> >>>>> at some point, you could roll up the days, in to weekly child tables, >>>>> then monthly tables, etc. >>>>> >>>>> I believe Bizgres has a new version of their system that does parallel >>>>> queries which would certainly speed things up. >>>>> >>>>> For your documents, you can do it by the day it was checked in, or >>>>> maybe >>>>> you have some other way of logically grouping, but the parent/child >>>>> table structure really helped to solve my problem of adding in >>>>> millions >>>>> of records each day. >>>>> >>>>> The closest thing in mysql is using merge tables, which is not really >>>>> practical when it comes time to do the joins to the tables. >>>>> >>>>> -brandon >>>>> >>>>> http://www.t3report.com - marketing intelligence for online marketing >>>>> and affiliate programs >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ---------------------------(end of >>>>> broadcast)--------------------------- >>>>> TIP 6: explain analyze is your friend >>>>> >>> >>> >>>> - -- >>> >>>> === The PostgreSQL Company: Command Prompt, Inc. === >>>> Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 >>>> PostgreSQL solutions since 1997 http://www.commandprompt.com/ >>>> UNIQUE NOT NULL >>>> Donate to the PostgreSQL Project: >>>> http://www.postgresql.org/about/donate >>>> PostgreSQL Replication: http://www.commandprompt.com/products/ >>> >>>> > > >> - ---------------------------(end of >> broadcast)--------------------------- >> TIP 6: explain analyze is your friend > > > >> - -- > >> === The PostgreSQL Company: Command Prompt, Inc. === >> Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 >> PostgreSQL solutions since 1997 http://www.commandprompt.com/ >> UNIQUE NOT NULL >> Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate >> PostgreSQL Replication: http://www.commandprompt.com/products/ > >> - -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240 PostgreSQL solutions since 1997 http://www.commandprompt.com/ UNIQUE NOT NULL Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG0HJ5ATb/zqfZUUQRAuEdAJwNwsr/XCsr85tElSVbRVMUHME+PACglbJK gj5cZgOtgEEjUPph0jpsOcw= =u7Ox -----END PGP SIGNATURE-----