"s d" <[EMAIL PROTECTED]> writes:
> I have about 6 tables that inherit from one table. They all have the
> exact same indexes but when i try to query all by a row (which is
> indexed, btree) the QP decides to do sequential scan for some of them
> (the bigger tables) rather than use the index.
Plea
Greg Smith wrote:
>
> Let's break this down into individual parts:
Great summary.
> 4) Is vacuuming a challenging I/O demand? Quite.
>
> Add all this up, and that fact that you're satisfied with how nice has
> worked successfully for you doesn't have to conflict with an opinion
> that it's not
Hi,
I have about 6 tables that inherit from one table. They all have the
exact same indexes but when i try to query all by a row (which is
indexed, btree) the QP decides to do sequential scan for some of them
(the bigger tables) rather than use the index.
Any ideas why that may happen?
I am using
On 18.05.2007, at 10:21, Kenneth Marshall wrote:
It is arguable, that updating the DB software version in an enterprise
environment requires exactly that: check all production queries on the
new software to identify any issues. In part, this is brought on by
the
very tuning that you performed
C Storm <[EMAIL PROTECTED]> writes:
> Essentially, I'm looking for the most efficient way to break a
> database into two 'shards' based on a top level table's
> primary key. For example, split a sales database into two using a
> territory.
I think what you are looking for here is partitioning, no
Sergei Shelukhin <[EMAIL PROTECTED]> writes:
> The query is very slow (3 minutes on test data), here's what takes all
> the time, from explain results:
>> Bitmap Heap Scan on tag (cost=897.06..345730.89 rows=115159 width=8)
>Recheck Cond: ((name)::text = 'blah'::text)
Sergei Shelukhin wrote:
Hi.
I have the following join condition in a query
"posttag inner join tag ON posttag.tagid = tag.id and tag.name =
'blah'"
tag.id is PK, I have indexes on posttag.tagid and tag.name both
created with all the options set to default.
PG version is 8.1.
The query is very
Any ideas?
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
This may be the wrong list to post to but I thought I'd post here
first since it is a performance related problem.
Essentially, I'm looking for the most efficient way to break a
database into two 'shards' based on a top level table's
primary key. For example, split a sales database into two using
On May 5, 9:44 am, CharlesBlackstone <[EMAIL PROTECTED]>
wrote:
> I think a lot of people are aware that an Opteron system has less
> bandwidth restrictions with a lot of processors, but that woodcrests
> don't have as good a memory controller and fall behind opterons after
> 4 cores or so. I'm as
Hi.
I have the following join condition in a query
"posttag inner join tag ON posttag.tagid = tag.id and tag.name =
'blah'"
tag.id is PK, I have indexes on posttag.tagid and tag.name both
created with all the options set to default.
PG version is 8.1.
The query is very slow (3 minutes on test da
Can you be a little more specific? What exactly are you trying to achieve
with pg_stats?
You can always get help for documentation at -->
http://www.postgresql.org/docs/8.2/static/view-pg-stats.html
--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)
On 5/13/07, Yudhvir Singh Sidhu <[EMAIL PROTEC
On Fri, May 18, 2007 at 06:40:31PM +0300, Liviu Ionescu wrote:
> > under some alignments of the planets 8.1 has similar problems.
>
> 8.1 might have similar problems, but the point here is different: if what
> was manually tuned to work in 8.1 confuses the 8.2 planner and performance
> drops so mu
On Fri, May 18, 2007 at 03:26:08PM -0700, Abu Mushayeed wrote:
> Also, this query ran today and it already finished. Today it was
> IO intensive.
Are you entirely sure that it's not a coincidence, and something
_else_ in the system is causing the CPU issues?
A
--
Andrew Sullivan | [EMAIL
14 matches
Mail list logo
