L and user tables on the memory-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
hill. 4Gb FC switches are common now, though finding a 4Gb
HBA for your 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
sell a competitive
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)---
TI
eheartedly* agree with Chris. An easy 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.
---
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.
>>
&g
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
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 --
; Which looks suspicious: 26308 MB/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
x27;obsid' and t2.value='oid080505');
NOTICE: QUERY PLAN:
Seq Scan on tmp_table2 (cost=0.00..9297614.80 rows=769844 width=6)
SubPlan
-> Index Scan using inv_index_2 on tmp_table2 t2 (cost=0.00..6.02
rows=1 width=0)
EXPLAIN
(This is after p
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
Joshua Marsh wrote:
>
>
> On 11/14/05, *Steve Wampler* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> However, even that seems to have a much higher cost than I'd expect:
>
>lab.devel.configdb=# explain delete from "tmp_tab
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
>
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 e
el.configdb(#WHERE at.id=a.id AND a.name='obsid' AND
a.value='oid080505');
NOTICE: QUERY PLAN:
Hash Join (cost=42674.42..100600.52 rows=296330 width=100)
-> Seq Scan on tmp_table2 at (cost=0.00..34975.88 rows=1539688 width=50)
-> Hash (cost=42674.32..42674.
DBC access to
PostgreSQL's COPY. (I have it installed here and *love* 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)?
I
underlying code to do this has
> to be not-too-complex.
It may not be that far off if you can use COPY instead of INSERT.
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.
, and the company went out of
>>business. We were serving "cornish game hens" at our frequent dinner
>>parties for months.
>
>
> This method might have been safer (and it works great with Apaches):
> http://eagle.auc.ca/~dreid/
Aha - VOIPOBD as well as VOIPOBT!
hese people adequately to avoid overloading a trunk line...) is probably
sufficiently hard to make it interesting. 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.
--
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 laug
which restricts all the backends to a single host?).
--
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 settings
ng the
task at hand - and a PG 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 broadc
available.
Once you've got 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)-
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 messa
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
ecause of the way
COPY 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 fo
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.
27;pgstattuple'
LANGUAGE 'c' WITH (isstrict);
psql:/usr/share/pgsql/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
t, right (the name doesn't seem to match)?
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
On Fri, Dec 05, 2003 at 09:54:52PM -0500, Robert Treat wrote:
> On Friday 05 December 2003 16:51, Steve Wampler wrote:
> > I need some help tracking down a sudden, massive slowdown
> > in inserts in one of our databases.
> >
> > PG: 7.2.3 (RedHat 8.0)
> >
> &g
n't know
much about postgresql 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?
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
same table, since 'attributes' is just a view into
'attributes_table'). The outer select is then locating all
records (~30-40K) that have any of those ids. Is that really
something a JOIN could be used for?
-Steve
--
Steve Wampler -- [EMAIL PROTECTED]
Quantum materiae materie
ings
over more conservative settings.
Any suggestions? Is there a better way to phrase the query
that would provide order-of-magnitude improvement?
Thanks!
Steve
--
Steve Wampler -- [EMAIL PROTECTED]
Quantum materiae materietur marmota monax si marmota
monax materiam possit mate
33 matches
Mail list logo
