On Sun, 26 Aug 2007 00:39:52 +0400, Martijn van Oosterhout
<[EMAIL PROTECTED]> wrote:
On Sun, Aug 26, 2007 at 01:22:58AM +0400, Max Zorloff wrote:
Hello.
shared_memory is used for caching. It is filled as stuff is used. If
you're not using all of it that means it isn't needed. Remember, it
On Sun, 26 Aug 2007 00:39:52 +0400, Martijn van Oosterhout
<[EMAIL PROTECTED]> wrote:
On Sun, Aug 26, 2007 at 01:22:58AM +0400, Max Zorloff wrote:
Hello.
I have a postgres 8.0 and ~400mb database with lots of simple selects
using indexes.
I've installed pgpool on the system. I've set num_ini
On Sun, Aug 26, 2007 at 01:22:58AM +0400, Max Zorloff wrote:
> Hello.
>
> I have a postgres 8.0 and ~400mb database with lots of simple selects
> using indexes.
> I've installed pgpool on the system. I've set num_init_children to 5 and
> here is the top output.
> One of postmasters is my demon
Hello.
I have a postgres 8.0 and ~400mb database with lots of simple selects
using indexes.
I've installed pgpool on the system. I've set num_init_children to 5 and
here is the top output.
One of postmasters is my demon running some insert/update tasks. I see
that they all use cpu heavily,
On Aug 25, 2007, at 2:58 PM, Erik Jones wrote:
On Aug 24, 2007, at 7:41 PM, Benjamin Arai wrote:
Hi,
I have an application which loads millions of NEW documents each
month
into a PostgreSQL tsearch2 table. I have the initial version
completed
and searching performance is great but my p
On Aug 24, 2007, at 7:41 PM, Benjamin Arai wrote:
Hi,
I have an application which loads millions of NEW documents each month
into a PostgreSQL tsearch2 table. I have the initial version
completed
and searching performance is great but my problem is that each time
a new
month rolls around
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Since I am using tsearch2 on the table I think there is going to be a
significant performance hit - e.g., I partition by batch (batches are
not separated by date, they are essentially random subsets of a much
larger data-set). I am querying thi
-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 durin
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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?
Benjamin
On Aug 25, 2007, at 9:18 AM, Joshua D. Drake wrote:
-BEGIN PG
-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
11 matches
Mail list logo
