while you weren't looking, Kevin Brown wrote:
[reordering bursty reads]
> In other words, it's a corner case that I strongly suspect
> isn't typical in situations where SCSI has historically made a big
> difference.
[...]
> But I rather doubt that has to be a huge penalty, if any. When a
> pro
while you weren't looking, Derek Buttineau|Compu-SOLVE wrote:
> I'm hoping this is the right place to send this.
The PostgreSQL Performance list, pgsql-performance@postgresql.org
would be more appropriate. I'm copying my followup there, as well.
As for your query, almost all the time is actually
On 8/24/05, Alexandre Barros <[EMAIL PROTECTED]> wrote:
> i wouldn't be so stunned if the newer machine was ( say ) twice faster
> than the older server, but over three times faster is disturbing.
RAID5 on so few spindles is a known losing case for PostgreSQL. You'd
be far, far better off doing
On Wed, May 5, 2010 at 10:17 PM, Neha Mehta wrote:
> I am trying to have synchronous master-master replication in PostgreSQL8.4
> using PgPool II. I am not able to configure PgPool on the system, it gives
> me an error, libpq is not installed or libpq is old.
>
(FYI: This topic is probably more ge
On Fri, May 21, 2010 at 4:53 PM, Richard Yen wrote:
> Any ideas why the query planner chooses a different query plan when using
> prepared statements?
A prepared plan is the best one the planner can come up with *in
general* for the query in question. If the distribution of the values
you're qu
On Fri, Mar 4, 2011 at 10:34 AM, Glyn Astill wrote:
> I'm wondering (and this may be a can of worms) what peoples opinions are on
> these schedulers? I'm going to have to do some real world testing myself
> with postgresql too, but initially was thinking of switching from our current
> CFQ bac
= 131072
Any advice, suggestions or comments of the "You bleeding idiot, why do
you have frob set to x?!" sort welcome. Unfortunately, if we can't
improve this, significantly, the powers what be will probably pass
on PostgreSQL, even though everything we've done so far--wi
er since you're not updating several foreign key'd fields bound to
> account.cust.prodid.
> UPDATE tempprod.prodid = prodid
> FROM account.cust
> WHERE temprod.did = cust.origid;
Not quite. Without this update, acount.cust.[sub]prodid are null. The
data was strewn across mul
hough I must say, ten minutes is nominally more than two orders of
mangitude performance improvement, versus several days.
Many thanks, Aaron.
/rls
--
Rosser Schwarz
Total Card, Inc.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
od"
Column | Type | Modifiers
---+---+---
debtid | character varying(10) | not null
pool | character varying(10) | not null
port | character varying(10) | not null
subprodid | bigint|
prodid| bigint
index "pg_toast_16408_index" now contains 12 row versions in 2 pages
DETAIL: 10 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
Having never more than glanced at the output of "vacuum verbose", I
can
while you weren't looking, Tom Lane wrote:
[trace]
`strace -p 21882` run behind the below query and plan ... below that.
# explain update account.cust set prodid = tempprod.prodid, subprodid =
tempprod.subprodid where origid = tempprod.debtid;
QUERY PLAN
---
INT, {SIG_DFL}, {0x804d404, [],
SA_RESTORER|SA_RES
TART, 0x420276f8}, 8) = 0 <0.13>
0.000532 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 <0.14>
0.000145 send(3, "X\0\0\0\4", 5, 0) = 5 <0.28>
0.000126 rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_IGN}, 8) = 0 <0.13>
0.000140 close(3) = 0 <0.33>
0.000147 rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_DFL}, 8) = 0 <0.13>
0.000197 open("/var/lib/pgsql/.psql_history", O_WRONLY|O_CREAT|O_TRUNC,
060
0) = 3 <0.000168>
0.000694 write(3, "\\d payment.batch\nalter sequence "..., 16712) =
16712 <
0.000209>
0.000311 close(3) = 0 <0.57>
0.055587 munmap(0x4003, 4096) = 0 <0.32>
0.000130 exit_group(0) = ?
/rls
--
Rosser Schwarz
Total Card, Inc.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
xed as our
tables are. I've dumped and rebuilt several times since then.
/rls
--
Rosser Schwarz
Total Card, Inc.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
that
it is, and that I've somehow been running 7.3.2 all along? `which
psql`, &c show the bindir from my configure, but I'm not sure that's
sufficient.
How would I tell? I don't remember any of the binaries having a
--version argument.
/rls
--
Rosser Schwarz
Total Card, Inc.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
at I know I never built 7.3.anything with 32K
BLCKSZ, never built 7.3.anything at all. If 7.3 were installed, would
it have any problem reading a 7.4 cluster?
/rls
--
Rosser Schwarz
Total Card, Inc.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Greg Spiegelberg wrote:
> I've been following this thread closely as I have the same problem
> with an UPDATE. Everything is identical here right down to the
> strace output.
> Has anyone found a workaround or resolved the problem? If not,
> I have test systems here which I can use to help up t
Greg Spiegelberg wrote:
> > Will advise.
After creating 100, 1K, 10K, 100K and 1M-row subsets of account.cust and
the corresponding rows/tables with foreign key constraints referring to
the table, I'm unable to reproduce the behavior at issue.
explain analyze looks like the following, showing th
ust enough C to be mildly dangerous.
/rls
--
Rosser Schwarz
Total Card, Inc.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
e--is
broken. The column they refer to is never touched; they
should remain utterly ignorant of whatever happens to other
columns in the same row.
/rls
--
Rosser Schwarz
Total Card, Inc.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
"recovery process" on databases that were entirely unused,
even for SELECT queries, at the time of the outage. The
only thing it might conceivably need to recover on them
is in-memory indices that were lost when power was lost.
--
Rosser Schwarz
Total Card, Inc.
-
it of fetching from disk, while your regular
queries hit the cache.
/rls
--
Rosser Schwarz
Total Card, Inc.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
On Fri, 02 Jul 2004 20:50:26 +0200, Edoardo Ceccarelli <[EMAIL PROTECTED]> wrote:
> This is the query:
> select max(KA) from annuncio
> wasn't supposed to do an index scan? it takes about 1sec to get the result.
> TIP 5: Have you checked our extensive FAQ?
I believe this is a FAQ.
See: http://
while you weren't looking, Francisco Reyes wrote:
> Is there any disadvantage of having the enable_seqscan off?
Plenty.
The planner will choose whichever plan looks "cheapest", based on the
information it has available (table size, statistics, &c). If a
sequential scan looks cheaper, and in you
while you weren't looking, Ray wrote:
> CREATE INDEX idx_doc_substr_doc_urn ON doc USING btree (SUBSTR(doc_urn,10));
CREATE INDEX idx_doc_substr_doc_urn ON doc USING btree ((SUBSTR(doc_urn,10)));
You need an additional set of parens around the SUBSTR() call.
/rls
--
:wq
-
while you weren't looking, Gary Doades wrote:
> The .NET Runtime will be a part of the next MS SQLServer engine.
It won't be long before someone writes a procedural language binding
to PostgreSQL for Parrot [1]. That should offer us a handful or six
more languages that can be used, including BAS
while you weren't looking, Merlin Moncure wrote:
> 2 way or 4 way Opteron depending on needs (looking on a price for 4-way?
> Go here: http://www.swt.com/qo3.html).
Try also the Appro 1U 4-way Opteron server, at:
http://www.appro.com/product/server_1142h.asp
I specced a 4-way 842 (1.6 GHz: litt
while you weren't looking, Greg Stark wrote:
> Back in the day, we used to have problems with our 1U dual pentiums. We
> attributed it to heat accelerating failure. I would fear four opterons in 1U
> would be damned hard to cool effectively, no?
Opterons actually run pretty coolly, comparatively.
while you weren't looking, Matthew Nuzum wrote:
> select accountid, min(atime) as atime, sessionid from usage_access
> group by accountid,sessionid;
Try something along the lines of:
select ua.accountid
, (select atime
from usage_access
where sessionid = ua.sessionid
On Mon, Jan 4, 2010 at 2:57 PM, Madison Kelly wrote:
> As for autovacuum, I assumed (yes, I know) that all v8.x releases enabled it
> by default. How would I confirm that it's running or not?
I believe it's not enabled by default in 8.1-land, and is as of 8.2
and later. Whether it's running or n
On Mon, Jan 30, 2012 at 9:46 AM, Saurabh wrote:
> I can not create the index after insertion because user can
> search the data as well while insertion.
Remember, DDL is transactional in PostgreSQL. In principle, you
should be able to drop the index, do your inserts, and re-create the
index with
On Tue, May 15, 2012 at 8:21 AM, Віталій Тимчишин wrote:
> We are using Areca controller with BBU. So as for me, question is: Can 520
> series be set up to handle fsyncs correctly?
No.
The cause for capacitors on SSD logic boards is that fsyncs aren't
flushed to NAND media, and hence persisted,
On Fri, Jul 20, 2012 at 2:27 PM, Ioannis Anagnostopoulos
wrote:
> On 20/07/2012 22:23, Claudio Freire wrote:
>> Misestimated row counts... did you try running an analyze, or upping
>> statistic targets?
> I have run analyse every so often. I think the problem is that as I get 16K
> new rows every
On Tue, Dec 11, 2012 at 5:17 PM, Evgeny Shishkin wrote:
> Actually most of low-end SSDs don't do write caching, they do not have
> enough ram for that.
>
AIUI, *all* SSDs do write-caching of a sort: writes are actually flushed to
the NAND media by erasing, and then overwriting the erased space, a
On Mon, Jan 28, 2013 at 10:54 AM, Craig James wrote:
> But if the drop-and-restore-trigger operation blocks all access to the
> tables, that's a problem.
>
Were the triggers in question created with "CREATE CONSTRAINT TRIGGER"? If
not, "ALTER TABLE foo DISABLE TRIGGER USER" may do what you need
On Thu, Dec 5, 2013 at 9:55 PM, Skarsol wrote:
> The rule is being used to return the id of the insert...
>
Take a look at the RETURNING clause of the INSERT statement. That should
meet your needs here without having to bother with rules.
rls
--
:wq
36 matches
Mail list logo
