We're having a problem with one of our queries being slow. It appears to be due
to the index being used to go from tableA to tableB.
Here are the tables:
CREATE TABLE tableA
(
table_idA int8 NOT NULL DEFAULT nextval('tableA_id_seq'::regclass),
CONSTRAINT table_idA_pk PRIMARY KEY (table_idA),
)
Scott Matseas <[EMAIL PROTECTED]> writes:
> If I enable sequential scan the Index Cond in
> question gets replaced with a Seq scan.
What other planner parameters have you been fooling with?
With no data in the tables, I get a reasonably sane-looking plan,
so I'm thinking you've chosen bad values
Hi,
I am using PostgreSQL 8.1.4 for an embedded
application. For some reason, vacuum is not able to identify rows that
are candidates for removal (i.e., mark space as available).
Background Info:
I observed some performance problems – our database
seemed to be using an unusuall
On Mon, 2006-08-21 at 11:50 -0700, Eamonn Kent wrote:
> So, my best guess is that something in our application is preventing
> vacuum from removing dead rows. What could cause this? Would it be
> caused by a long-living transaction? What is the best way to track
> the problem down...right now,
Tom Lane wrote:
What other planner parameters have you been fooling with?
Hi Tom,
The other parameters that have been changed are:
set join_collapse_limit to 1
set enable_sort to off
We are using version 8.1.3. We've noticed the query plan changing depending
on the amount of data in the tables
"Eamonn Kent" <[EMAIL PROTECTED]> writes:
> I am using PostgreSQL 8.1.4 for an embedded application. For some
> reason, vacuum is not able to identify rows that are candidates for
> removal (i.e., mark space as available).
> ...
> We run auto vacuum and I can see from the logs that it is running q
I'm exhausted to try all performance tuning ideas, like following
parameters
shared_buffers
fsync
max_fsm_pages
max_connections
shared_buffers
work_mem
max_fsm_pages
effective_cache_size
random_page_cost
I believe all above have right size and values, but I just can not get
higher tps mor
On Mon, 2006-08-21 at 16:45 -0400, Marty Jia wrote:
> I'm exhausted to try all performance tuning ideas, like following
> parameters
>
> shared_buffers
> fsync
By "tuning" fsync, what do you mean? Did you turn it off?
If you turned fsync off, that could compromise your data in case of any
kind
Not much we can do unless you give us more info about how you're testing
(pgbench setup), and what you've done with the parameters you listed
below. It would also be useful if you told us more about your drive
array than just "3Par". We need to know the RAID level, number/speed of
disks, whether
I am trying to decide what kind of storage options to use for a pair of
good database servers, a primary and a read-only that can be a failover.
Here is what I'm thinking so far:
(1) We have a nice NetApp that can do iSCSI. It has a large (multi-GB)
battery-backed cache so it could potentially per
Jeff,
Thanks for your response, I did turn the fsync off, no performance
improvement.
Since the application is a network monring program, data is not critical
for us.
Marty
-Original Message-
From: Jeff Davis [mailto:[EMAIL PROTECTED]
Sent: Monday, August 21, 2006 5:23 PM
To: Marty Ji
Marty Jia wrote:
I'm exhausted to try all performance tuning ideas, like following
parameters
shared_buffers
fsync
max_fsm_pages
max_connections
shared_buffers
work_mem
max_fsm_pages
effective_cache_size
random_page_cost
I believe all above have right size and values, but I just can no
On Mon, 2006-08-21 at 15:45, Marty Jia wrote:
> I'm exhausted to try all performance tuning ideas, like following
> parameters
>
> shared_buffers
> fsync
> max_fsm_pages
> max_connections
> shared_buffers
> work_mem
> max_fsm_pages
> effective_cache_size
> random_page_cost
>
> I believe a
Hello,
Thanks for the help...It appears that a transaction is indeed being
opened and remains idle. I am able to identify the postgreSQL backend
process that is associated with the transaction, however, I need to
further localize the issue. We have around 22 (postgres) backend
processes associat
Any ideas of how to identify the application process that is the
postgres process (whose id I know). Perhaps I need to turn on a
different log flag?
select * from pg_stat_activity will give you the pid :)
Joshua D. Drake
Thanks
Ike
-Original Message-
From: Tom Lane [mailto:
Tom Lane wrote:
> I wrote:
> > Looking at this, I wonder if there isn't a bug or at least an
> > inefficiency in 8.1. The KeysEqual short circuit tests are still there
> > in ri_triggers.c; aren't they now redundant with the test in triggers.c?
> > And don't they need to account for the special ca
16 matches
Mail list logo
