"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Tapir appears to be failing because make check wants more than 10
> connections for testing. What I don't understand is why it's being
> limited to 10.
Your SysV IPC limits are too small --- apparently it's not so much
shared memory as semaphores that a
Tapir appears to be failing because make check wants more than 10
connections for testing. What I don't understand is why it's being
limited to 10. initdb -d doesn't help either...
...
selecting default max_connections ... 10
selecting default shared_buffers/max_fsm_pages ... 32MB/204800
creating
On 11/11/06, Neil Conway <[EMAIL PROTECTED]> wrote:
The patch still leaks result7 circa line 1400 (CVS HEAD). I didn't look
closely, but you probably also leak result7 circa line 1209, if result6
is NULL.
New version of the patch attached (against CVS HEAD) that fixes these
two issues.
(Yeah
On Fri, Nov 10, 2006 at 08:17:09PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > On Sun, Nov 05, 2006 at 11:01:40AM -0500, Neil Conway wrote:
> >> Presumably those are just the standard warnings we can't easiy
> >> eliminate. If not, can you post them please?
> > They all appear harmless.
[EMAIL PROTECTED] writes:
> On Sun, Nov 05, 2006 at 11:01:40AM -0500, Neil Conway wrote:
>> Presumably those are just the standard warnings we can't easiy
>> eliminate. If not, can you post them please?
> They all appear harmless.
The reason those "uninitialized variable" warnings got away from u
[EMAIL PROTECTED] writes:
> On Sun, Nov 05, 2006 at 09:11:07AM +, Simon Riggs wrote:
>> If that hit you then we're gonna get a few more people trip the same
>> way. Do you have any suggestions as to how to avoid that experience for
>> others?
> I believe the release notes are inadequate. I've
On Tue, 2006-11-07 at 16:21 +1100, Brendan Jurd wrote:
> Minor fix to the previous patch; result7 was not being cleared at the
> end of the block.
The patch still leaks result7 circa line 1400 (CVS HEAD). I didn't look
closely, but you probably also leak result7 circa line 1209, if result6
is NULL
On Fri, 2006-11-10 at 16:46 +0100, Zeugswetter Andreas ADI SD wrote:
> > I'm not sure this really solves that problem because there
> > are still DELETEs to consider but it does remove one factor
> > that exacerbates it unnecessarily.
>
> Yea, so you still need to vaccum the large table regular
On Fri, 2006-11-10 at 17:04 +0100, Zeugswetter Andreas ADI SD wrote:
> > > True, but Nikhil has run tests that clearly show HOT outperforming
> > > current situation in the case of long running transactions. The need
>
> > > to optimise HeapTupleSatisfiesVacuum() and avoid long chains does
> > >
Hi,
On 11/10/06, Zeugswetter Andreas ADI SD <[EMAIL PROTECTED]> wrote:
> > True, but Nikhil has run tests that clearly show HOT outperforming> > current situation in the case of long running transactions. The need
> > to optimise HeapTupleSatisfiesVacuum() and avoid long chains does> > still remain
Hi,
On 11/10/06, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
On 11/10/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <
[EMAIL PROTECTED]> writes:> On 11/10/06, Tom Lane <[EMAIL PROTECTED]> wrote:> (2) Isn't this full of race conditions?
> I agree, there could be race conditions. But
On Fri, 2006-11-10 at 20:38 +0200, Hannu Krosing wrote:
> Ühel kenal päeval, R, 2006-11-10 kell 12:19, kirjutas Simon Riggs:
> > On Thu, 2006-11-09 at 18:28 -0500, Tom Lane wrote:
>
> > > > HOT can only work in cases where a tuple does not modify one of the
> > > > columns defined in an index on t
Ühel kenal päeval, R, 2006-11-10 kell 12:19, kirjutas Simon Riggs:
> On Thu, 2006-11-09 at 18:28 -0500, Tom Lane wrote:
> > > HOT can only work in cases where a tuple does not modify one of the
> > > columns defined in an index on the table, and when we do not alter the
> > > row length of the tup
On Fri, 2006-11-10 at 17:00 +0100, Zeugswetter Andreas ADI SD wrote:
> > > 2. locking should be easier if only the original heap page is
> involved.
> >
> > Yes, but multi-page update already happens now, so HOT is not
> > different on that point.
>
> I was thinking about the case when you "pull
> > True, but Nikhil has run tests that clearly show HOT outperforming
> > current situation in the case of long running transactions. The need
> > to optimise HeapTupleSatisfiesVacuum() and avoid long chains does
> > still remain a difficulty for both HOT and the current situation.
>
>
> Yes
> > 2. locking should be easier if only the original heap page is
involved.
>
> Yes, but multi-page update already happens now, so HOT is not
> different on that point.
I was thinking about the case when you "pull back" a tuple, which seems
to be more
difficult than what we have now.
Andreas
> > 1. It doubles the IO (original page + hot page), if the new row
would
> > have fit into the original page.
>
> That's an awfully big IF there. Even if you use a fillfactor
> of 50% in which case you're paying a 100% performance penalty
I don't see where the 50% come from ? That's only
Gevik Babakhani wrote:
Folks,
Does anyone know where I can find information about the PG communication
protocol specifications between backend and frontend?
Yeah, there's a chapter about that in the manual:
http://www.postgresql.org/docs/8.1/interactive/protocol.html
--
Heikki Linnakangas
On 11/10/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:> On 11/10/06, Tom Lane <[EMAIL PROTECTED]> wrote:> (2) Isn't this full of race conditions?
> I agree, there could be race conditions. But IMO we can handle those.Doubtless you can prevent races by introd
Folks,
Does anyone know where I can find information about the PG communication
protocol specifications between backend and frontend?
Regards,
Gevik.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://arch
jatrojoomla wrote:
Hi Group!
I am trying to work & connect php wirh PGSQL on Red Hat ES 3.
I got some Important path like:
/usr/share/pgsql/contrib
/usr/include/pgsql
/usr/bin
But I don't know how to start/stop pgsql server, Insert data from
client pgsql , view database files, admin datab
Hi Group!
I am trying to work & connect php wirh PGSQL on Red Hat ES 3.
I got some Important path like:
/usr/share/pgsql/contrib
/usr/include/pgsql
/usr/bin
But I don't know how to start/stop pgsql server, Insert data from
client pgsql , view database files, admin database & configuration
f
Hi,
> True, but Nikhil has run tests that clearly show HOT outperforming
> current situation in the case of long running transactions. The need to
> optimise HeapTupleSatisfiesVacuum() and avoid long chains does still
> remain a difficulty for both HOT and the current situation.
>
Yes, I carried
> > I think the vision is that the overflow table would never be very
> > large because it can be vacuumed very aggressively. It has only
tuples
> > that are busy and will need vacuuming as soon as a transaction ends.
> > Unlike the main table which is mostly tuples that don't need
> > vacuumi
On 11/10/06, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Fri, 2006-11-10 at 12:32 +0100, Zeugswetter Andreas ADI SD wrote:> e.g. a different header seems no easier in overflow than in heap
True. The idea there is that we can turn frequent update on/off fairlyeasily for normal tables since there are n
On Fri, 2006-11-10 at 12:32 +0100, Zeugswetter Andreas ADI SD wrote:
> > > As more UPDATEs take place these tuple chains would grow, making
> > > locating the latest tuple take progressively longer.
>
> > More generally, do we need an overflow table at all, rather
> > than having these overflow
Hi,I think the vision is that the overflow table would never be very large
because it can be vacuumed very aggressively. It has only tuples that are busyand will need vacuuming as soon as a transaction ends. Unlike the main tablewhich is mostly tuples that don't need vacuuming.
Thats right. vacuum
Hi,
> > This allows the length of a typical tuple chain to be extremely short in> > practice. For a single connection issuing a stream of UPDATEs the chain> > length will no more than 1 at any time.
>> Only if there are no other transactions being held open, which makes> this claim a lot weaker.T
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Seems like "altering the row length" isn't the issue, it's just "is
>> there room on the page for the new version". Again, a generous
>> fillfactor would give you more flexibility.
>
> The copy-back operation can only work if the tuple fits in the same
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> 1. It doubles the IO (original page + hot page), if the new row would
> have fit into the original page.
That's an awfully big IF there. Even if you use a fillfactor of 50% in which
case you're paying a 100% performance penalty *al
Oops, pressed send too early. Ignore the one-line reply I just sent...
Simon Riggs wrote:
On Thu, 2006-11-09 at 18:28 -0500, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
HOT can only work in cases where a tuple does not modify one of the
columns defined in an index on the table, a
Simon Riggs wrote:
On Thu, 2006-11-09 at 18:28 -0500, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
HOT can only work in cases where a tuple does not modify one of the
columns defined in an index on the table, and when we do not alter the
row length of the tuple.
Seems like "alteri
On Thu, 2006-11-09 at 18:28 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > As more UPDATEs take place these tuple chains would grow, making
> > locating the latest tuple take progressively longer.
>
> This is the part that bothers me --- particularly the random-access
> nat
Am Freitag, 10. November 2006 08:29 schrieb Jeremy Drake:
> I figured out that the -g flag was being surreptitiously added to my
> CFLAGS. It was like pulling teeth trying to get the -g flag out. I tried
> --disable-debug to configure, which did not work. I had to do
> CFLAGS=-O2 ./configure ...
On 11/10/06, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Tom Lane wrote:> (Actually, the assumption that you can throw an additional back-pointer> into overflow tuple headers is the worst feature of this proposal in> that regard --- it's really not that easy to support multiple header
> formats.)
> > As more UPDATEs take place these tuple chains would grow, making
> > locating the latest tuple take progressively longer.
> More generally, do we need an overflow table at all, rather
> than having these overflow tuples living in the same file as
> the root tuples? As long as there's a b
Tom Lane wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
Yes. The last bit in the t_infomask is used up to mark presence of overflow
tuple header. But I believe there are few more bits that can be reused.
There are three bits available in the t_ctid field as well (since ip_posid
needs maximu
On 11/10/06, Tom Lane <[EMAIL PROTECTED]
> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:> Yes. The last bit in the t_infomask is used up to mark presence of overflow
> tuple header. But I believe there are few more bits that can be reused.
> There are three bits available in the t_ctid field
On Fri, 2006-11-10 at 09:51 +0200, Hannu Krosing wrote:
> > What are the advantages of HOT over SITC (other than cool name) ?
>
> still wondering this, is it just the abilty to span multiple pages ?
Multiple page spanning, copy back/VACUUM support, separate overflow
relation to prevent heap grow
39 matches
Mail list logo
