Bruce,
> The magic block required in all PostgreSQL-supported libraries
> is checked to guarantee compatibility. For this reason, non-PostgreSQL
> libraries cannot be loaded in this way.
Um, that's identical to the old text. Try:
The magic block is required in all PostgreSQL-
"Bruce Momjian" wrote
>
> Any idea why there is such a variance in the result? The second run
> looks quite slow.
>
No luck so far. It is quite repeatble in my machine -- runing times which
show a long execution time: 2, 11, 14, 21 ... But when I do strace, the
weiredness disappered totally. H
On Thu, Jun 15, 2006 at 10:35:19PM -0400, Tom Lane wrote:
> Chris Campbell <[EMAIL PROTECTED]> writes:
> > I heard an interesting feature request today: preventing the
> > execution of a DELETE or UPDATE query that does not have a WHERE clause.
> These syntaxes are required by the SQL spec. Furt
Tom Lane wrote:
> Bruce Momjian writes:
> > Josh Berkus wrote:
> >>> The magic block present in all PostgreSQL-supported libraries
> >>> is checked to guarantee compatibility. For this reason, non-PostgreSQL
> >>> libraries cannot be loaded in this way.
> >>
> >> you need "must be" before "prese
Qingqing Zhou wrote:
>
> "Bruce Momjian" wrote
> >
> > > -- After patch --
> > >
> > > real0m1.275s
> > > user0m0.097s
> > > sys 0m0.160s
> > >
> > > real0m4.063s
> > > user0m0.663s
> > > sys 0m0.377s
> > >
> > > real0m1.259s
> > > user0m0.073s
> > > sys 0m0.16
Bruce Momjian writes:
> Josh Berkus wrote:
>>> The magic block present in all PostgreSQL-supported libraries
>>> is checked to guarantee compatibility. For this reason, non-PostgreSQL
>>> libraries cannot be loaded in this way.
>>
>> you need "must be" before "present".
> Uh, the point is not
On Tue, 2006-06-13 at 14:18 -0400, Kris Kennaway wrote:
> On Tue, Jun 13, 2006 at 12:29:14PM -0500, Jim C. Nasby wrote:
>
> > Unless supersmack has improved substantially, you're unlikely to find
> > much interest. Last I heard it was a pretty brain-dead benchmark. DBT2/3
> > (http://sourceforge.n
"Bruce Momjian" wrote
>
> > -- After patch --
> >
> > real0m1.275s
> > user0m0.097s
> > sys 0m0.160s
> >
> > real0m4.063s
> > user0m0.663s
> > sys 0m0.377s
> >
> > real0m1.259s
> > user0m0.073s
> > sys 0m0.160s
>
> I assume the above is just running the same te
"letizia leo" <[EMAIL PROTECTED]> wrote
>
> Transaction T1 updates a given tuple -- xmax is set to T1 on that tuple
> ...
> later on, T1 aborts... we believe that in this circumstance
HEAP_XMAX_INVALID should
> be set on the tuple to signal that the tuple was not actually "deleted" by
T1 since
Brandon E Hofmann <[EMAIL PROTECTED]> writes:
> In plpgsql, how do you return back a result set that is determined and
> generated at runtime based on a report request?
If I understand what you are asking for, you don't.
> Also why does plpgsql require you to define what is returned?
plpgsql is
Hi,
i want to make this patch usable
http://archives.postgresql.org/pgsql-patches/2004-12/msg00089.php
as i understand, it needs some refactor, at least plpgsql support,
pg_dump support and docs.
any comments are welcome...
also the autor states this:
From: hyip ( at ) site ( dot ) uottawa
letizia leo <[EMAIL PROTECTED]> writes:
> Transaction T1 updates a given tuple -- xmax is set to T1 on that tuple
> ...
> later on, T1 aborts... we believe that in this circumstance
> HEAP_XMAX_INVALID should be set on the tuple to signal that the tuple was not
> actually "deleted" by T1 since
Josh Berkus wrote:
> Bruce,
>
> > The magic block present in all PostgreSQL-supported libraries
> > is checked to guarantee compatibility. For this reason, non-PostgreSQL
> > libraries cannot be loaded in this way.
>
> you need "must be" before "present".
>
> Also, this is in runt
Qingqing Zhou wrote:
>
> "Tom Lane" <[EMAIL PROTECTED]> wrote
> >
> > Hm? I don't see any improvement there:
> >
>
> I was referening this sentence, though I am not sure why that's the
> expectation:
> >
> > "Bruce Momjian" wrote
> > If the patch worked, the first and third times will be simila
On Tue, Jun 13, 2006 at 03:55:38PM -0500, Jim Nasby wrote:
>
> On Jun 12, 2006, at 10:38 AM, Kris Kennaway wrote:
> >>>FYI, the biggest source of contention is via semop() - it might be
> >>>possible to optimize that some more in FreeBSD, I don't know.
> >>
> >>Yeah, I've seen PostgreSQL on FreeBS
On Tue, Jun 13, 2006 at 12:29:14PM -0500, Jim C. Nasby wrote:
> Unless supersmack has improved substantially, you're unlikely to find
> much interest. Last I heard it was a pretty brain-dead benchmark. DBT2/3
> (http://sourceforge.net/projects/osdldbt) is much more realistic (based
> on TPC-C and
When using a temp table in plpgsql functions that has columns comprised
from many tables populated by joins, how do you specify a temp table return
type when its generated by select into and dropped dynamically? I get an
error when I specify returns setof temp_table. Also when I specify a
perman
On Tue, Jun 13, 2006 at 12:29:14PM -0500, Jim C. Nasby wrote:
> > > Can you provide the actual commands you used to setup and run the test?
> >
> > I actually forget all the steps I needed to do to get super-smack
> > working with postgresql since it required a lot of trial and error for
> > a da
I am studying the postgresql kernel and the following question arose... I hope somebody out there can help me find the answers to my doubts. Scenario: Transaction T1 updates a given tuple -- xmax is set to T1 on that tuple ... later on, T1 aborts... we believe that in this circumstance HEAP_XMAX_
When I read the post related to the battery-backed disks, I come to this
question: What can we improve/reduce if we have them? Since our fsync
methods is already be able support that (thought not automatically), we may
want to look into other parts. One issue is the xlog and our aim is (1)
reduce
NTT has some ideas about index creation during a large amount of data loading.
Our approach is the following: index tuples are created at the same time as heap
tuples and added into heapsort. In addition, we use old index tuples as sorted
list if the target table has already data. It is not nece
Chris Campbell <[EMAIL PROTECTED]> writes:
> I heard an interesting feature request today: preventing the
> execution of a DELETE or UPDATE query that does not have a WHERE clause.
These syntaxes are required by the SQL spec. Furthermore, it's easy
to imagine far-more-probable cases in which th
I heard an interesting feature request today: preventing the
execution of a DELETE or UPDATE query that does not have a WHERE clause.
The user was worried about a typo leading to:
DELETE FROM very_important_table
and deleting all the data. Or doing something similar with an UPDATE:
UPD
On 6/15/06, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
already should be fixed ...
yes, it's working now. thanks
--
regards,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bi
already should be fixed ...
On Thu, 15 Jun 2006, Jaime Casanova wrote:
Hi,
is it me or there is a problem with the anoncvs?
i get this when trying to update HEAD
[EMAIL PROTECTED]:~/pgsql$ ping anoncvs.postgresql.org
PING svr4.postgresql.org (66.98.251.159) 56(84) bytes of data.
From gphou-6
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> wrote
>> Hm? I don't see any improvement there:
> I was referening this sentence, though I am not sure why that's the
> expectation:
>> "Bruce Momjian" wrote
>> If the patch worked, the first and third times will be sim
"Tom Lane" <[EMAIL PROTECTED]> wrote
>
> Hm? I don't see any improvement there:
>
I was referening this sentence, though I am not sure why that's the
expectation:
>
> "Bruce Momjian" wrote
> If the patch worked, the first and third times will be similar, and
> the second time will be high.
>
-
Le jeudi 15 juin 2006 22:29, Tom Lane a écrit :
> Currently, the Red Hat and (I believe) PGDG RPMs set up ident
> authentication as the default, by running initdb with
> --auth='ident sameuser'
> I think several other binary distros do the same.
Just to notice Mandriva still provide postgr
Hi,
is it me or there is a problem with the anoncvs?
i get this when trying to update HEAD
[EMAIL PROTECTED]:~/pgsql$ ping anoncvs.postgresql.org
PING svr4.postgresql.org (66.98.251.159) 56(84) bytes of data.
From gphou-66-98-241-125.ev1.net (66.98.241.125) icmp_seq=1
Destination Host Unreacha
Bruce,
> The magic block present in all PostgreSQL-supported libraries
> is checked to guarantee compatibility. For this reason, non-PostgreSQL
> libraries cannot be loaded in this way.
you need "must be" before "present".
Also, this is in runtime-config.sgml?
--
--Josh
J
Josh Berkus wrote:
> Bruce,
>
> > The report is incomplete. I need three outputs:
> >
> > stats off
> > stats on
> > stats on, patched
> >
> > He only reported two sets of results.
>
> You need stats off, patched too.
No need --- stats off, patched too, should be the same as stats o
Josh Berkus writes:
> You need stats off, patched too.
Shouldn't really be necessary, as the code being patched won't be
executed if stats aren't being collected...
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'k
Bruce,
> The report is incomplete. I need three outputs:
>
> stats off
> stats on
> stats on, patched
>
> He only reported two sets of results.
You need stats off, patched too.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast
Bruce Momjian wrote:
> Would some people please run the attached test procedure and report back
> the results? I basically need to know the patch is an improvement on
> more platforms than just my own. Thanks
Debian Sarge/AMD64 Kernel 2.6.16.16 (all tests done multiple times with
variation of l
Currently, the Red Hat and (I believe) PGDG RPMs set up ident
authentication as the default, by running initdb with
--auth='ident sameuser'
I think several other binary distros do the same. It was pointed out to
me recently that this does not work real well anymore on Fedora. It's
fine on
Bruce Momjian wrote:
> Would some people please run the attached test procedure and report back
> the results? I basically need to know the patch is an improvement on
> more platforms than just my own. Thanks
OpenBSD 3.9-current/x86:
without stats:
0m6.79s real 0m1.56s user 0m1.12s
Simon Riggs <[EMAIL PROTECTED]> writes:
> The LRU moves each time we do FileRead or FileWrite, not just on
> open/close operations.
Sure, but those still require kernel calls, so the cost of a couple of
pointer swings is negligible. There's no way that the logical
complexity of sometimes maintain
Patch applied. Thanks.
---
Bruce Momjian wrote:
>
> I have update the patch at:
>
> ftp://candle.pha.pa.us/pub/postgresql/mypatches/strict
>
> I re-did it to use STRICT for Oracle PL/SQL syntax. I don't think we
Josh Berkus wrote:
> Andrew,
>
> > Worth a comment in the config file?
>
> Possibly. Or the docs.
SGML config docs updated:
The magic block present in all PostgreSQL-supported libraries
is checked to guarantee compatibility. For this reason, non-PostgreSQL
libraries c
On Thu, 2006-06-15 at 17:50 +0800, Qingqing Zhou wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> wrote
> >
> > Can we do the same for the file descriptors in fd.c?
> >
> > Very often the total number of file descriptors is much less than the
> > maximum, so it would make sense to only maintain the LRU w
Andrew,
> Worth a comment in the config file?
Possibly. Or the docs.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
I am not sure where to go on this patch. I agree there was a long delay
in getting you feedback on it, and some of the feedback was harsh.
However, the patch does need more work to get into PostgreSQL because it
has to work in all cases. It is a neat feature, for sure.
At this point, I have pu
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Any reason why fields in the catalog tables don't have descriptions?
The documentation for the catalogs is in catalogs.sgml. I would much
rather see people seeking info go to the HTML docs; pg_description could
at best provide a small part of what you
Any reason why fields in the catalog tables don't have descriptions? If
I were to create a patch to add them, what part of the code would I need
to look at?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard:
Tom Lane wrote:
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> > Obviously it matches your expectation.
>
> Hm? I don't see any improvement there:
>
> > --Before patch --
> > real0m1.149s
> > real0m1.121s
> > real0m1.128s
>
> > -- After patch --
> > real0m1.275s
> > real0m4
I've looked into what it would take to add an INCLUDING CONSTRAINTS option to
CREATE TABLE LIKE. This would make it much more practical to use CREATE TABLE
LIKE to create new partitions instead of having to create new children then
remove them from the inheritance before loading and manipulating d
Simon Riggs <[EMAIL PROTECTED]> writes:
> Can we do the same for the file descriptors in fd.c?
I haven't seen any indication that fd.c is a performance bottleneck,
so I don't see the point.
Also, there is an external constraint: we can't simply have thousands
of open file descriptors; on most pla
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> Obviously it matches your expectation.
Hm? I don't see any improvement there:
> --Before patch --
> real0m1.149s
> real0m1.121s
> real0m1.128s
> -- After patch --
> real0m1.275s
> real0m4.063s
> real0m1.259s
Martijn van Oosterhout writes:
> If you do a \d, does that load every tuple from pg_class into the
> catcache?
Many of 'em, not sure about "all".
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extens
Tom Lane wrote:
> Buildfarm member emu is failing in some branches with
>
> checking libintl.h usability... yes
> checking libintl.h presence... no
> configure: WARNING: libintl.h: accepted by the compiler, rejected by the
> preprocessor!
> configure: WARNING: libintl.h: proceeding with the prepr
"Simon Riggs" <[EMAIL PROTECTED]> wrote
>
> Can we do the same for the file descriptors in fd.c?
>
> Very often the total number of file descriptors is much less than the
> maximum, so it would make sense to only maintain the LRU when we are
> using more than 50%-75% of the maximum.
>
I am not ag
Moving from -committers to -hackers:
On Wed, 2006-06-14 at 23:08 -0300, Tom Lane wrote:
> On small-to-middling databases this wins
> because maintaining the LRU list is a waste of time.
Sounds good.
Can we do the same for the file descriptors in fd.c?
Very often the total number of file descr
On Wed, Jun 14, 2006 at 08:04:31PM -0400, Tom Lane wrote:
> So I'm pretty strongly inclined to just dike out the limit. If you're
> running a database big enough to hit the existing limit, you can well
> afford to put more memory into the catcache.
If you do a \d, does that load every tuple from
Bruce Momjian wrote:
> Would some people please run the attached test procedure and report
> back the results? I basically need to know the patch is an
> improvement on more platforms than just my own. Thanks
>
>
---
>
[s
54 matches
Mail list logo
