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
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
> >
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 h
Ü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 anythi
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,
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 gath
"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
re
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, an
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
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
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 signif
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 th
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 broadcast)-
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 using
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 actual
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
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,
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 operatio
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 casc
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 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 th
Ü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)
> > >
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, Devri
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
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 rollb
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]> wri
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
+
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 differ
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
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
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
> mu
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 optimizer/exe
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 k
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 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 primitiv
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 Hyper
36 matches
Mail list logo
