> UPDATE table SET table.par = table.par + 1
> WHERE table.key IN ('value1', 'value2', ... , 'value1200' )
How fast is the query alone, i.e.
SELECT * FROM table
WHERE table.key IN ('value1', 'value2', ... , 'value1200' )
---(end of broadcast)
UPDATE table SET table.par = table.par + 1
WHERE table.key IN ('value1', 'value2', ... , 'value1200' )
How fast is the query alone, i.e.
SELECT * FROM table
WHERE table.key IN ('value1', 'value2', ... , 'value1200' )
Also, post the output of '\d table' and EXPLAIN ANALYZE UPDATE...
Chris
I have had a cluster failure on a table. It most likely was due to space.
I do not not have the error message anymore, but it was indicating that it
was most likely a space problem. The partition was filled to 99%. The
table is about 56 GB and what I believe to be the new table that it was
writi
On Wed, Mar 10, 2004 at 12:35:15AM -0300, Marcus Andree S. Magalhaes wrote:
> Guys,
>
> I got a Java program to tune. It connects to a 7.4.1 postgresql server
> running Linux using JDBC.
>
> The program needs to update a counter on a somewhat large number of
> rows, about 1200 on a ~130k rows tab
"Shea,Dan [CIS]" <[EMAIL PROTECTED]> writes:
> The problem is that it did not clean itself up properly.
Hm. It should have done so. What were the exact filenames and sizes of
the not-deleted files?
> I can not find any reference to 361716097 in the pg_class table.
You are looking at pg_cla
"Shea,Dan [CIS]" <[EMAIL PROTECTED]> writes:
>> The problem is that it did not clean itself up properly.
>Hm. It should have done so. What were the exact filenames and sizes of
>the not-deleted files?
361716097 to 361716097.39 are 1073741824 bytes.
361716097.40 is 186105856 bytes.
> I can
On Tue, Mar 02, 2004 at 10:54:23AM +, teknokrat wrote:
> thanks, i remember a thread about problems with flags passed to gcc on
> solaris. I was wondering if there had been any resolution and if the
> defaults for 7.4 are considered Ok.
As near as I can tell, -O2 is used by default on Solari
Hmm... from the 'performance' point of view, since the data comes from
a quite complex select statement, Isn't it better/quicker to have this
select replaced by a select into and creating a temporary database?
> The problem, as I understand it, is that 7.4 introduced massive
> improvements in h
On Wed, Mar 10, 2004 at 02:02:23PM -0300, Marcus Andree S. Magalhaes wrote:
> Hmm... from the 'performance' point of view, since the data comes from
> a quite complex select statement, Isn't it better/quicker to have this
> select replaced by a select into and creating a temporary database?
Defin
On Wed, 10 Mar 2004, Marcus Andree S. Magalhaes wrote:
>
> Guys,
>
> I got a Java program to tune. It connects to a 7.4.1 postgresql server
> running Linux using JDBC.
>
> The program needs to update a counter on a somewhat large number of
> rows, about 1200 on a ~130k rows table. The query is
> "GS" == Greg Spiegelberg <[EMAIL PROTECTED]> writes:
GS> I've been waiting all day for a pg_restore to finish on a test system
GS> identically configured as our production in hardware and software
GS> with the exception prod is 7.3.5 and test is 7.4.1.
GS> The file it's restoring from is ab
On Mar 2, 2004, at 5:54 AM, teknokrat wrote:
Andrew Sullivan wrote:
On Thu, Feb 26, 2004 at 12:46:23PM +, teknokrat wrote:
I've read about the place. Would using -O3 be an improvement?
In my experience, it's not only not an improvement, it sometimes
breaks the code. That's on 8, though, not 9
Tom Lane wrote:
Greg Spiegelberg <[EMAIL PROTECTED]> writes:
I turned syslog back on and the restore slowed down again. Turned
it off and it sped right back up.
We have heard reports before of syslog being quite slow. What platform
are you on exactly? Does Richard's suggestion of turning off sy
Greg Spiegelberg <[EMAIL PROTECTED]> writes:
> If the log and database were on the same disk I'd be okay with the
> current workaround. If the ``-'' gave me near the same performance as
> turning syslog off I'd be okay with that too. However, neither of these
> are the case so there has to be som
Tom Lane wrote:
Greg Spiegelberg <[EMAIL PROTECTED]> writes:
If the log and database were on the same disk I'd be okay with the
current workaround. If the ``-'' gave me near the same performance as
turning syslog off I'd be okay with that too. However, neither of these
are the case so there has
You could also consider not using syslog at all: let the postmaster
output to its stderr, and pipe that into a log-rotation program.
I believe some people use Apache's log rotator for this with good
results.
Not an option I'm afraid. PostgreSQL just jams and stops logging after
the first rotation
It might depend on how you're rotating it.
Try the copy/truncate method instead of moving the log file. If you move
the log file to another filename you usually have to restart the app
doing the logging before it starts logging again.
Chris.
-Original Message-
From: [EMAIL PROTECTED]
[ma
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> You could also consider not using syslog at all: let the postmaster
>> output to its stderr, and pipe that into a log-rotation program.
>> I believe some people use Apache's log rotator for this with good
>> results.
> Not an option I'm afraid
18 matches
Mail list logo
