Message-ID: <012c01c7e75d$68c4ef20$c901a8c0@blaptop>
From: "Brandon Shalton" <brandon@cydataservices.com>
To: "Benjamin Arai" <me@benjaminarai.com>
Cc: "PostgreSQL" <pgsql-general@postgresql.org>,
	<pgsql-performance@postgresql.org>
References: <3147EF26-2649-4FDF-BD86-2DB0AF8460FC@benjaminarai.com>
	<0be901c7e6cb$a2b13320$c901a8c0@blaptop>
	<46CF85EE.5040805@commandprompt.com>
	<F6B156AD-BE6D-4300-871A-E3DE0491AA11@benjaminarai.com>
	<46D0564A.7030405@commandprompt.com>
	<29A8F3CE-03F9-4E92-A354-6F4FC3C810F4@benjaminarai.com>
Subject: Re: [PERFORM] Partioning tsearch2 a table into chunks and accessing
	via views
Date: Sat, 25 Aug 2007 14:17:53 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit

>
> 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?
>

depends.. since indexes would be hit for each child table, the time for 
query is dependent on the amount of data that is indexed in each table.

the querying of the parent is still pretty quick given dual processor and a 
fast array filestorage device.

given your situation, i would give the parent/child approach a child.  I 
haven't checked in postgres if it is has it has Joshua had replied, but I do 
know bizgres does as i have been running this configuration for the last 3 
years and it solved my problem of importing 30-60M records in a day and 
still being able to query the database for data.

-brandon

http://www.t3report.com - marketing intelligence for online marketing and 
affiliate programs