Hello list,
I am working on a Entity-Attribute-Value (EAV) database using PostgreSQL
8.4.7. The basic problem is that when joining multiple times different
entities the planner thinks that there is vastly less rows to join than
there is in reality and decides to use multiple nested loops for t
On 2011-03-18 01:51, Oliver Charles wrote:
Hello,
At MusicBrainz we're looking to get a new database server, and are
hoping to buy this in the next couple of days. I'm mostly a software
guy, but I'm posting this on behalf of Rob, who's actually going to be
buying the hardware. Here's a quote of
Thanks , it works now .. :-)
Here is the output :
pdc_uima=# SELECT count(*) from page_content WHERE publishing_date like
'%2010%' and
pdc_uima-# content_language='en' and content is not null and
isprocessable = 1 and
pdc_uima-# to_tsvector('english',content) @@
to_tsquery('english','Mujahid
On Thu, Mar 17, 2011 at 6:51 PM, Oliver Charles
wrote:
> Hello,
>
> At MusicBrainz we're looking to get a new database server, and are
> hoping to buy this in the next couple of days. I'm mostly a software
> guy, but I'm posting this on behalf of Rob, who's actually going to be
> buying the hardwa
On Mar 17, 2011, at 5:51 PM, Oliver Charles wrote:
> Hello,
>
> At MusicBrainz we're looking to get a new database server, and are
> hoping to buy this in the next couple of days. I'm mostly a software
> guy, but I'm posting this on behalf of Rob, who's actually going to be
> buying the hardware
On Thu, Mar 17, 2011 at 9:13 AM, Jeff wrote:
> hey folks,
>
> Running into some odd performance issues between a few of our db boxes.
> While trying to speed up a query I ran it on another box and it was twice
> as fast. The plans are identical and various portions of the query run in
> the same
> -Original Message-
> From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-
> ow...@postgresql.org] On Behalf Of Jeff
> Sent: Thursday, March 17, 2011 9:14 AM
> To: pgsql-performance@postgresql.org
> Cc: Brian Ristuccia
> Subject: [PERFORM] Xeon twice the performance of
On 03/17/2011 09:25 AM, Michael Andreasen wrote:
Hi,
I've been looking around for information on doing a pg_restore as fast as
possible. It is for a backup machine so I am not interested in anything like
crash recovery or anything else that would impact speed of load. I just want to
go from n
Hello,
At MusicBrainz we're looking to get a new database server, and are
hoping to buy this in the next couple of days. I'm mostly a software
guy, but I'm posting this on behalf of Rob, who's actually going to be
buying the hardware. Here's a quote of what we're looking to get:
I'm working t
Hi,
I've been looking around for information on doing a pg_restore as fast as
possible. It is for a backup machine so I am not interested in anything like
crash recovery or anything else that would impact speed of load. I just want
to go from no database to database there as fast as possible. The
Thanks, we'll give these a try.
Tim
On Thu, Mar 17, 2011 at 2:13 PM, Kevin Grittner wrote:
> Timothy Garnett wrote:
>
> > We'd still be interested in other suggestions for convincing the
> > query planner not to pick the bad plan in this case
>
> You could try boosting cpu_tuple_cost. I've se
Timothy Garnett wrote:
> We'd still be interested in other suggestions for convincing the
> query planner not to pick the bad plan in this case
You could try boosting cpu_tuple_cost. I've seen some evidence that
the default number is a bit low in general, so it wouldn't
necessarily be bad to
Hi all,
The bl_number is nearly a unique value per a row (some small portion are
duplicated on a handful or rows).
We need the unique on pair of bl_number and month, but evaluating current
usage we don't make use of selecting on just month currently (though we
expect to have usage scenarios that
On 3/17/11 9:42 AM, J Sisson wrote:
On Thu, Mar 17, 2011 at 10:13 AM, Jeff wrote:
hey folks,
Running into some odd performance issues between a few of our db boxes.
We've noticed similar results both in OLTP and data warehousing conditions here.
Opteron machines just seem to lag behind *espe
On Thu, Mar 17, 2011 at 1:42 PM, J Sisson wrote:
> On Thu, Mar 17, 2011 at 10:13 AM, Jeff wrote:
>> hey folks,
>>
>> Running into some odd performance issues between a few of our db boxes.
>
> We've noticed similar results both in OLTP and data warehousing conditions
> here.
>
> Opteron machines
On Thu, Mar 17, 2011 at 10:13 AM, Jeff wrote:
> hey folks,
>
> Running into some odd performance issues between a few of our db boxes.
We've noticed similar results both in OLTP and data warehousing conditions here.
Opteron machines just seem to lag behind *especially* in data
warehousing. Smal
hey folks,
Running into some odd performance issues between a few of our db
boxes. While trying to speed up a query I ran it on another box and
it was twice as fast. The plans are identical and various portions of
the query run in the same amount of time - it all boils down to most
of t
Kenneth Marshall wrote:
> I think this is it:
>
>
http://archives.postgresql.org/pgsql-committers/2010-01/msg00021.php
Looks like it. Based on the commit date, that would be a 9.0
change. Based on the description, I'm not sure it fixes Derrick's
problem; the workaround of explicitly using m
"Kevin Grittner" writes:
> Derrick Rice wrote:
>> Kevin Grittner >> there is a feature to probe the end of an index's range in
>>> situations where data skew was often causing less than optimal
>>> plans to be chosen.
>> Was this introduced in 9.0 or was it earlier?
> I don't remember when it
On Thu, Mar 17, 2011 at 09:49:45AM -0500, Kevin Grittner wrote:
> Derrick Rice wrote:
> > Kevin Grittner >
> >> there is a feature to probe the end of an index's range in
> >> situations where data skew was often causing less than optimal
> >> plans to be chosen.
> >
> > Was this introduced in
Derrick Rice wrote:
> Kevin Grittner
>> there is a feature to probe the end of an index's range in
>> situations where data skew was often causing less than optimal
>> plans to be chosen.
>
> Was this introduced in 9.0 or was it earlier?
I don't remember when it was added. I took a stab at s
On Wed, Mar 16, 2011 at 5:56 PM, Kevin Grittner wrote:
> there is a feature to probe the end of an index's range in
> situations where data skew was often causing less than optimal plans
> to be chosen.
>
Was this introduced in 9.0 or was it earlier? My company hasn't introduced
integrated supp
Thank you. I had pg_archivecleanup added in recovery.conf, but on second
look had a typo in the archive dir path. After this change in recovery.conf
and postgres restart, its fine now. Once my archive dir got cleaned up , i
noticed my /var/postgres/data/pg_xlog dir on master also got cleaned up
On
> *Modified Query :-
>
> *SELECT count(*) from page_content
> WHERE publishing_date like '%2010%' and content_language='en' and
> content is not null and isprocessable = 1 and
> to_tsvectOR('english',content) @@ to_tsquery('english','Mujahid' ||
> 'jihad' || 'Militant' || 'fedayeen' || 'insurgent'
24 matches
Mail list logo
