On Wed, 2005-12-07 at 01:04 -0800, J. Andrew Rogers wrote:
Opteron boards get pretty damn close to Big Iron SMP fabric
performance in a cheap package. Given how many companies have
announced plans to produce Opteron server boards with Infiniband
fabrics directly integrated into
On Dec 6, 2005, at 9:09 PM, Gregory Maxwell wrote:
Eh, why would light limited delay be any slower than a disk on FC the
same distance away? :)
In any case, performance of PG on iscsi is just fine. You can't blame
the network... Doing multimaster replication is hard because the
locking
In article [EMAIL PROTECTED],
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
mysql SELECT EXTRACT(MICROSECOND FROM '2003-01-02 10:30:01.00123');
+---+
| EXTRACT(MICROSECOND FROM '2003-01-02 10:30:01.00123') |
On Dec 6, 2005, at 11:42 PM, Markus Schiltknecht wrote:
Does anybody have latency / roundtrip measurements for current
hardware?
I'm interested in:
1Gb Ethernet,
10 Gb Ethernet,
InfiniBand,
probably even p2p usb2 or firewire links?
In another secret life, I
Andrew,
And if postgres could actually use an infiniband fabric for
clustering a single database instance across Opteron servers, that
would be very impressive...
That's what we do with Bizgres MPP. We've implemented an interconnect to do
the data shuffling underneath the
On Tue, Dec 06, 2005 at 08:54:42PM -0700, Trent Shipley wrote:
It would be nice if Postgresql supported multi-octet raw data. Certainly a
lot of what you would do with it would be similar to bytea, but the basic
string functions would be overloaded so that the unit of work would be a
Hi,
Zoltan Boszormenyi írta:
Jan Wieck írta:
On 12/5/2005 1:03 PM, Zoltan Boszormenyi wrote:
Jan Wieck írta:
On 12/4/2005 5:10 PM, Zoltan Boszormenyi wrote:
I found this in the SQL2003 draft:
4.14.7 Identity columns
... An identity column has a start value, an increment, a maximum
Hi,
I'd like to inform the people who does not read Planet PostgreSQL
Command Prompt Inc.has just hired me for my community work I have been
doing so far, like PostgreSQL RPM stuff and other PostgreSQL related
RPMs, such as Slony-I, pgpool, PostGIS, etc) and website things. That
means I'll spend
Christopher Kings-Lynne wrote:
Why aren't 'minutes' considered too? Because they aren't 'seconds'.
Well, seconds aren't microseconds either.
Yeah, they are: it's just one field. The other way of looking at it
(that everything is seconds) is served by extract(epoch).
Well, it's
I had an open 8.1 item that was:
o fix foreign trigger timing issue
Would someone supply text for a TODO entry on this, as I don't think we
fixed it in 8.1.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
I think this is the foreign key trigger timing issue.
---
Darcy Buskermolen wrote:
On Friday 09 September 2005 08:46, Stephan Szabo wrote:
On Fri, 9 Sep 2005, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On 12/6/05, Hannu Krosing wrote:
1) run a transaction repeatedly, trying to hit a point of no concurrent
transactions, encance the odds by locking out starting other
transactions for a few (tenths or hundredths of) seconds, if it
succeeds, record SNAP1, commit and and continue, else rollback,
Hannu Krosing [EMAIL PROTECTED] writes:
But that said, realistically *any* solution has to obtain a lock at some
time
to make the schema change. I would say pretty much any O(1) (constant time)
outage is at least somewhat acceptable as contrasted with the normal index
build which
Devrim Gunduz Wrote:
Command Prompt Inc.has just hired me for my community work I have been
doing so far, like PostgreSQL RPM stuff and other PostgreSQL related
RPMs, such as Slony-I, pgpool, PostGIS, etc) and website things. That
means I'll spend more time on these.
Congratulations, Devrim.
Ühel kenal päeval, K, 2005-12-07 kell 13:36, kirjutas Greg Stark:
Hannu Krosing [EMAIL PROTECTED] writes:
But that said, realistically *any* solution has to obtain a lock at some
time
to make the schema change. I would say pretty much any O(1) (constant
time)
outage is at least
On Tue, Dec 06, 2005 at 12:35:43AM -0500, Jan Wieck wrote:
We do not plan to implement replication inside the backend. Replication
needs are so diverse that pluggable replication support makes a lot more
sense. To me it even makes more sense than keeping transaction support
outside of the
On Wednesday 07 December 2005 09:33, Bruce Momjian wrote:
I had an open 8.1 item that was:
o fix foreign trigger timing issue
Stephan Szabo had this to say to me when I was asking him about his progress
on this issue a while back.
There are some fundamental issues right now between
On Wed, 7 Dec 2005, Bruce Momjian wrote:
I had an open 8.1 item that was:
o fix foreign trigger timing issue
Would someone supply text for a TODO entry on this, as I don't think we
fixed it in 8.1.
I'd split this into two separate items now.
Fix before delete triggers on cascaded
We've suspected for awhile that once we'd fixed the buffer manager's use
of a single global BufMgrLock, the next contention hotspot would be the
lock manager's LockMgrLock. I've now seen actual evidence of that in
profiling pgbench: using a modified backend that counts LWLock-related
wait
Tom,
This would also explain some things we've seen during benchmarking here
at EnterpriseDB. I like your idea and, as I'm on my way out, will
think about it a bit tonight.
Similarly, I don't see the any forward-looking reason for keeping the
separate hash tables used for the LockMethodIds. Or,
On Wed, 2005-12-07 at 16:59 -0500, Tom Lane wrote:
I've now seen actual evidence of that in
profiling pgbench: using a modified backend that counts LWLock-related
wait operations,
So it seems it's time to start thinking about how to reduce contention
for the LockMgrLock
You're right to be
Tom Lane wrote:
Interesting proposal.
LockReleaseAll is also interesting from a performance point of view,
since it executes at every transaction exit. If we divide PGPROC's
PROCLOCK list into N lists then it will be very easy for LockReleaseAll
to take only the partition locks it actually
On 12/6/2005 9:03 PM, Euler Taveira de Oliveira wrote:
Hi,
I'm doing some tests with a 700 columns' table. But when I try to load
some data with INSERT or COPY I got that message. I verified that the
BLCKZ is limiting the tuple size but I couldn't have a clue why it's
not using TOAST. I'm
Anyone remember this patch?
http://gorda.di.uminho.pt/community/pgsqlhooks/
The discussion seems to be pretty minimal:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg00859.php
Does anyone see a need to investigate it further?
Chris
---(end of
Alvaro Herrera [EMAIL PROTECTED] writes:
Is hashtable overhead all that large? Each table could be made
initially size-of-current-table/N entries. One problem is that
currently the memory freed from a hashtable is not put back into shmem
freespace, is it?
Yeah; the problem is mainly that
Simon Riggs [EMAIL PROTECTED] writes:
My view would be that the LockMgrLock is not relevant for all workloads,
but I want even more to be able to discuss whether it is, or is not, on
an accepted basis before discussions begin.
Certainly. I showed the evidence that it is currently a
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Anyone remember this patch?
http://gorda.di.uminho.pt/community/pgsqlhooks/
The discussion seems to be pretty minimal:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg00859.php
Does anyone see a need to investigate it further?
I had
This seems like a useful feature to add, allowing for easy built-in
verticle partitioning. Are there issues with the patch as-is? (Other
than it probably should have gone to -patches...)
On Thu, Dec 01, 2005 at 05:59:08PM +0900, Junji TERAMOTO wrote:
Hi all,
I wrote a experimental patch for a
On Thu, Dec 01, 2005 at 12:32:12PM -0500, Qingqing Zhou wrote:
Neil Conway [EMAIL PROTECTED] wrote
This would also be useful when diagnosing bad query plans: for example,
setting enable_seqscan=false often causes the planner to disregard the
use of *any* sequential scan, anywhere in the
Jim C. Nasby [EMAIL PROTECTED] writes:
This seems like a useful feature to add, allowing for easy built-in
verticle partitioning. Are there issues with the patch as-is?
Other than the ones mentioned by the poster?
It seemed to me more like a not-too-successful experiment than something
ready
On Fri, Dec 02, 2005 at 03:25:58PM -0500, Greg Stark wrote:
Postgres would have no trouble building an index of the existing data using
only shared locks. The problem is that any newly inserted (or updated) records
could be missing from such an index.
To do it you would then have to gather
On Sat, Dec 03, 2005 at 10:15:25AM -0500, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
What's worse, once you have excluded writes you have to rescan the entire
table to be sure you haven't missed anything. So in the scenarios where this
whole thing is actually interesting, ie
Ühel kenal päeval, N, 2005-12-08 kell 00:16, kirjutas Jim C. Nasby:
On Sat, Dec 03, 2005 at 10:15:25AM -0500, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
What's worse, once you have excluded writes you have to rescan the entire
table to be sure you haven't missed anything. So in
On Thu, Dec 08, 2005 at 08:57:42AM +0200, Hannu Krosing wrote:
??hel kenal p??eval, N, 2005-12-08 kell 00:16, kirjutas Jim C. Nasby:
On Sat, Dec 03, 2005 at 10:15:25AM -0500, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
What's worse, once you have excluded writes you have to
On Wed, Dec 07, 2005 at 12:06:23AM -0500, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Rather than hard-wiring a special case for any of these things, I'd much
rather see us implement INSERT...RETURNING and UPDATE...RETURNING as per
previous
On Thu, Dec 08, 2005 at 12:59:47AM -0500, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
This seems like a useful feature to add, allowing for easy built-in
verticle partitioning. Are there issues with the patch as-is?
Other than the ones mentioned by the poster?
It seemed to me
36 matches
Mail list logo
