Hi,
I could not find and normal solution for that issue. But I am using
some workarounds for that issue.
The solution, that I am using now is to create an index for every bit
of your bitmap field.
So something like
CREATE INDEX idx_hobbybit_0_limited
ON versionA.user_fast_index
USING btree
What about saying?:
TBL1.CATEGORY = TBL2.CATEGORY
Are you sure you understood what was the question?
Is the TBL1.CATEGORY = TBL2.CATEGORY the same as TBL1.CATEGORY
TBL2.CATEGORY 0?
---(end of broadcast)---
TIP 6: explain analyze is your
Hi all,
I have a problem with DELETE performance with postgres 7.4.
I have a database with 2 great tables (about 150,000 rows) continuously
updated, with 1000 - 1200 INSERT per second and 2 or 3 huge DELETE per
minute, in which we delete almost all the rows inserted in the 2 tables
during the
Galantucci Giovanni wrote:
I have a problem with DELETE performance with postgres 7.4.
You should consider upgrading. While I don't recall any particular
enhancements that would directly help with this problem, 8.2 is
generally faster.
I have a database with 2 great tables (about 150,000 rows)
Heikki Linnakangas [EMAIL PROTECTED] writes:
Galantucci Giovanni wrote:
For 1 or 2 hours we update only one table, and everything goes ok, where
DELETE last at most 6 or 7 seconds.
Then for a minute we do INSERT on both table, and everything continue
going ok, with DELETE that last about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gavin M. Roy escribió:
How many backends do you have at any given time? Have you tried using
something like pgBouncer to lower backend usage? How about your IO
situation? Have you run something like sysstat to see what iowait is
at?
backends
On Wed, Sep 12, 2007 at 03:01:12PM -0500, Erik Jones wrote:
On Sep 12, 2007, at 2:19 PM, Frank Schoep wrote:
On Sep 12, 2007, at 9:07 PM, Scott Marlowe wrote:
On 9/12/07, Mikko Partio [EMAIL PROTECTED] wrote:
?
Aren't you mixing up REINDEX and CLUSTER?
?
Either one does what a vacuum
On Mon, Sep 17, 2007 at 2:49 AM, in message
[EMAIL PROTECTED], valgog
[EMAIL PROTECTED] wrote:
What about saying?:
TBL1.CATEGORY = TBL2.CATEGORY
Are you sure you understood what was the question?
Is the TBL1.CATEGORY = TBL2.CATEGORY the same as TBL1.CATEGORY
TBL2.CATEGORY 0?
On Thu, Sep 13, 2007 at 01:58:10AM -0400, Greg Smith wrote:
On Wed, 12 Sep 2007, Scott Marlowe wrote:
I'm getting more and more motivated to rewrite the vacuum docs. I think
a rewrite from the ground up might be best... I keep seeing people
doing vacuum full on this list and I'm thinking
Kevin Grittner [EMAIL PROTECTED] writes:
On Mon, Sep 17, 2007 at 2:49 AM, in message
[EMAIL PROTECTED], valgog
[EMAIL PROTECTED] wrote:=20
Are you sure you understood what was the question?
Is the TBL1.CATEGORY = TBL2.CATEGORY the same as TBL1.CATEGORY
TBL2.CATEGORY 0?
Yes, given that
On Mon, Sep 17, 2007 at 8:37 AM, in message [EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Kevin Grittner [EMAIL PROTECTED] writes:
On Mon, Sep 17, 2007 at 2:49 AM, in message
[EMAIL PROTECTED], valgog
[EMAIL PROTECTED] wrote:=20
Are you sure you understood what was the question?
Hi,
A little clarification. Actually, TBL1.CATEGORY and/or TBL2.CATEGORY may
hold a binary value having multiple binary(ies) '1'.
Each binary value column represent an business attribute.
If a binary value column is equal to '1', it means that the business
attribute is True,
otherwise it is
Hi,
Decibel! wrote:
Actually, in this case, I suspect that latency will be far more critical
than overall bandwidth. I don't know if it's inherent to Gig-E, but my
limited experience has been that Gig-E has higher latency than 100mb.
I've been looking for some benchmarks, but it's rather hard
Hi all,
Please see the section marked as PROBLEM in ORIGINAL QUERY plan below.
You can see it's pretty slow. Oddly enough, an index for facility_address_id
is available but not being used, but I suspect it's questionable whether it
would be an improvement.
I knew that the filter was best
On 9/17/07, Carlo Stonebanks [EMAIL PROTECTED] wrote:
Hi all,
Please see the section marked as PROBLEM in ORIGINAL QUERY plan below.
You can see it's pretty slow. Oddly enough, an index for facility_address_id
is available but not being used, but I suspect it's questionable whether it
would
Well, there goes my dream of getting a recommendation that will deliver a
blinding insight into how to speed up all of my queries a thousand-fold.
Thanks Merlin!
-Original Message-
From: Merlin Moncure [mailto:[EMAIL PROTECTED]
Sent: September 17, 2007 8:03 PM
To: Carlo Stonebanks
Cc:
On 9/17/07, Carlo Stonebanks [EMAIL PROTECTED] wrote:
Well, there goes my dream of getting a recommendation that will deliver a
blinding insight into how to speed up all of my queries a thousand-fold.
that's easy...delete your data! :-)
merlin
---(end of
Thanks, it worked. Client happy. Big bonus in the mail.
-Original Message-
From: Merlin Moncure [mailto:[EMAIL PROTECTED]
Sent: September 17, 2007 8:18 PM
To: Carlo Stonebanks
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Query works when kludged, but would prefer best
Merlin Moncure [EMAIL PROTECTED] writes:
On 9/17/07, Carlo Stonebanks [EMAIL PROTECTED] wrote:
Please see the section marked as PROBLEM in ORIGINAL QUERY plan below.
This looks like it might be the problem tom caught and rigged a solution to:
We have upgraded postgres from 7.2.4 to 8.2.0.
We have program which executes COPY command and our new database is changed
having some extra columns in some tables.
Because of this, COPY commands are failing.
So, we wanted the option to COPY the data without specifying column names.
Thanks,
Sonal
20 matches
Mail list logo
