-backed file
systems? I wouldn't think the performance impact of leaving
the rest of the stuff on disk would be that large.
Or does losing WAL files mandate a new initdb?
--
Steve Wampler -- swamp...@noao.edu
The gods that smiled on your birth are now laughing out loud.
--
Sent via pgsql
computer might be a trick. 2Gb HBAs are everywhere in
FC land. That's a premium price solution, however, and I don't know
anything about how well PG would perform with a FC SAN. We use our
SAN for bulk science data and leave the PGDB on a separate machine
with local disk.
--
Steve Wampler
networked filesystem]).
In any event, you're at least limited by ethernet speeds, if not more.
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
---(end of broadcast)---
TIP 2: Don't 'kill -9
way to get the pg_dump
for the upgrade target to run with the upgradable source
would work wonders. (Instructions included, of course.)
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
---(end of broadcast
Joshua D. Drake wrote:
The reason you want the dual core cpus is that PostgreSQL can only
execute 1 query per cpu at a time,...
Is that true? I knew that PG only used one cpu per query, but how
does PG know how many CPUs there are to limit the number of queries?
--
Steve Wampler -- [EMAIL
David Boreham wrote:
Steve Wampler wrote:
Joshua D. Drake wrote:
The reason you want the dual core cpus is that PostgreSQL can only
execute 1 query per cpu at a time,...
Is that true? I knew that PG only used one cpu per query, but how
does PG know how many CPUs
Arjen van der Meijden wrote:
On 15-11-2005 15:18, Steve Wampler wrote:
Magnus Hagander wrote:
(This is after putting an index on the (id,name,value) tuple.) That
outer seq scan
is still annoying, but maybe this will be fast enough.
I've passed this on, along with the (strong
this will be fast enough.
I've passed this on, along with the (strong) recommendation that they
upgrade PG.
Thanks!!
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
---(end of broadcast)---
TIP
/sec???
Eh? That looks more like ~25.7 MB/sec, assuming 1MB = 1024*1024 bytes.
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet
)
- Hash (cost=42674.32..42674.32 rows=38 width=50)
- Seq Scan on tmp_table2 a (cost=0.00..42674.32 rows=38 width=50)
EXPLAIN
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
---(end of broadcast
Scott Lamb wrote:
On Nov 14, 2005, at 2:07 PM, Steve Wampler wrote:
# SELECT at.id FROM tmp_table2 at, tmp_tabl2e a
# WHERE at.id=a.id and a.name='obsid' and a.value='oid080505';
Isn't this equivalent?
select id from tmp_table2 where name = 'obsid' and value = 'oid080505';
Probably
Tom Lane wrote:
Steve Wampler [EMAIL PROTECTED] writes:
We've got an older system in production (PG 7.2.4). Recently
one of the users has wanted to implement a selective delete,
but is finding that the time it appears to take exceeds her
patience factor by several orders of magnitude. Here's
Scott Lamb wrote:
On Nov 14, 2005, at 3:52 PM, Steve Wampler wrote:
Scott Lamb wrote:
On Nov 14, 2005, at 2:07 PM, Steve Wampler wrote:
# SELECT at.id FROM tmp_table2 at, tmp_tabl2e a
# WHERE at.id=a.id and a.name='obsid' and a.value='oid080505';
Isn't this equivalent?
select id
* it - it
gives outstanding performance.) However, it hasn't made into an
official release yet. I don't know why, perhaps there's
a problem yet to be solved with it ('works for me', though)?
Is this still on the board? I won't upgrade past 7.4 without it.
--
Steve Wampler -- [EMAIL PROTECTED]
The gods
.
But comparing Bulkload to INSERT is a bit apples-orangish.
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http
.
This method might have been safer (and it works great with Apaches):
http://eagle.auc.ca/~dreid/
Aha - VOIPOBD as well as VOIPOBT! What more can one want?
VOIPOCP, I suppose...
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud
Mohan, Ross wrote:
VOIP over BitTorrent?
Now *that* I want to see. Aught to be at least as interesting
as the TCP/IP over carrier pigeon experiment - and more
challenging to boot!
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud
. Then there are the problems of
different accents, dilects, and languages ;)
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map
the data partitioned, the question becomes one of
how to inhance performance/scalability. Have you considered RAIDb?
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
---(end of broadcast)---
TIP 7: don't
database server isn't written to be
distributed across hosts regardless of the distribution of the
data across filesystems.
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
---(end of broadcast)---
TIP
On Mon, 2004-06-07 at 02:26, Kris Jurka wrote:
On Sat, 5 Jun 2004, Steve Wampler wrote:
[I want to use copy from JDBC]
I made a patch to the driver to support COPY as a PG extension.
...
http://archives.postgresql.org/pgsql-jdbc/2003-12/msg00186.php
Thanks Kris - that patch worked
On Mon, 2004-06-07 at 10:40, Steve Wampler wrote:
Thanks Kris - that patch worked beautifully and bumped the
insert rate from ~1000 entries/second to ~9000 e/s in my
test code.
As a followup - that 9000 e/s becomes ~21,000 e/s if I don't
have the java code also dump the message to standard
is implemented to only use a file?
Is there something else I can do? Ultimately, this will end
up on a machine running 1+0 RAID, so I expect that will give
me some performance boost as well, but I'd like to push it
up as best I can with my current hardware setup.
Thanks for any advice!
-Steve
--
Steve
On Sun, 2003-12-07 at 09:52, Tom Lane wrote:
Steve Wampler [EMAIL PROTECTED] writes:
Hmmm, I have a feeling that's not as obvious as I thought... I can't
identify the index (named 'id_index') in the output of vacuum verbose.
In 7.2, the index reports look like
Index %s: Pages %u
)?
The table's entry is:
NOTICE: --Relation attributes_table--
NOTICE: Pages 639: Changed 0, Empty 0; Tup 52846: Vac 0, Keep 0, UnUsed 48.
Total CPU 0.00s/0.01u sec elapsed 0.01 sec.
Thanks!
Steve
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing
/contrib/pgstattuple.sql:4: ERROR: stat failed
on file '$libdir/pgstattuple': No such file or directory
I don't need this right now (a reindex seems to have fixed
our problem for now...), but it sounds like it would be useful
in the future.
Thanks!
Steve
--
Steve Wampler -- [EMAIL PROTECTED
internals/configuration.
Thanks!
Steve
--
Steve Wampler -- [EMAIL PROTECTED]
The gods that smiled on your birth are now laughing out loud.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org
On Sun, 2003-07-13 at 14:50, Steve Wampler wrote:
I've got a simple nested query:
select * from attributes where id in (select id from
attributes where (name='obsid') and (value='oid00066'));
that performs abysmally. I've heard this described as the
'classic WHERE IN' problem
28 matches
Mail list logo
