Tom Lane kirjutas E, 30.06.2003 kell 06:39:
Hannu Krosing [EMAIL PROTECTED] writes:
Tom Lane kirjutas E, 30.06.2003 kell 01:21:
Who's still using 1.5, I guess is the question? And are they likely
to be updating their PG installation when they're not updating Python?
I guess that anyone
Hi,
I noticed the patch:
http://archives.postgresql.org/pgsql-patches/2003-06/msg00366.php
isn't in the patch queue. Is the patch OK?
If not please say what is wrong with it.
Thank you,
- Stuart
---(end of broadcast)---
TIP 2: you can get off all
On Fri, 27 Jun 2003, Bruno Wolff III wrote:
On Thu, Jun 26, 2003 at 09:27:23 -0700,
Shirish Reddy [EMAIL PROTECTED] wrote:
Hi,
One of the issues that is preventing us from migrating
from an Oracle DB to Postgres is that Table
Partitioning is not available in Postgres yet.
Hello:
Thanks another wuestion in this case about oidvector i'm reviewing
oidvectorsend() at backend/utils/adt/oid.c and seems that for this
datatype the server sends only array data, i'm rigth ??, i think yes but
i want to be sure ;) ( and i think the same can be applied to int2vector
?? )
Carlos Guzman Alvarez [EMAIL PROTECTED] writes:
Thanks another wuestion in this case about oidvector i'm reviewing
oidvectorsend() at backend/utils/adt/oid.c and seems that for this
datatype the server sends only array data, i'm rigth ??, i think yes but
i want to be sure ;) ( and i think the
Hello:
Right, the fixed-length array types are a whole 'nother critter.
Thanks
--
Best regards
Carlos Guzmán Álvarez
Vigo-Spain
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining
Moving to pgsql-hackers@
On Mon, 2003-06-30 at 12:03, sumit wrote:
Thanks for letting know. Could you also let me know the exact
syntax, I mean, we are not sure whether GROUP BY CUBE(...) is followed by
a HAVING clause. Kindly inform us soon so that we can make the changes and
send
On Mon, 30 Jun 2003, deststar wrote:
Hi,
I noticed the patch:
http://archives.postgresql.org/pgsql-patches/2003-06/msg00366.php
isn't in the patch queue. Is the patch OK?
I think it was just that Bruce hasn't gotten to it.
If not please say what is wrong with it.
I just checked out a new
Hannu Krosing writes:
Tom Lane kirjutas E, 23.06.2003 kell 01:29:
Kevin Jacobs [EMAIL PROTECTED] writes:
Attached is a patch that removes all of the RExec code from plpython
from the current PostgreSQL CVS. In addition, plpython needs to be
changed to an untrusted language in
On Mon, 30 Jun 2003, Stephan Szabo wrote:
On Mon, 30 Jun 2003, deststar wrote:
Hi,
I noticed the patch:
http://archives.postgresql.org/pgsql-patches/2003-06/msg00366.php
isn't in the patch queue. Is the patch OK?
I think it was just that Bruce hasn't gotten to it.
If not please
Stephan Szabo [EMAIL PROTECTED] writes:
As a side question, it looks to me that the code stores the first trigger
records in memory and then after some point starts storing all new records
on disk. Is this correct? I'd wonder if that's really what you want in
general, since I'd think that
Hi,
I have interesting question that stops me now.
Suppose I have 2 functions
1. preparestate
2. doajob
first allocates some state using
MemoryContextAlloc(TopTransactionContext)
or something, another function using that memory.
question is how I lookup that memory in second function doajob?
Maksim Likharev wrote:
Of cause I can return a handle from first function, pointer and accept
that pointer in second function, but in this case I have to check
that pointer on validity and so on...
Is there any good practice ( some way to do so ) for that?
Best way I've come up with to do this
I'm improving the Dllist in these direction:
1) Avoid if statements in insertion/remove phase, for instance now the
AddHeader appear like this:
void
DLAddHead(Dllist *l, Dlelem *e)
{
Dlelem *where = l-dll_master_node-dle_next;
e-dle_next = where;
e-dle_prev = where-dle_prev;
Mendola Gaetano [EMAIL PROTECTED] writes:
I'm improving the Dllist in these direction:
AFAIR, catcache.c is the *only* remaining backend customer for Dllist,
and so any improvement for Dllist that breaks catcache is hardly an
improvement, no?
1) Avoid if statements in insertion/remove phase,
I just noticed that the OSDL benchmarks for PostgreSQL appear to require
PostgreSQL be compiled with INDEX_MAX_KEYS as 64 rather than the default
of 32.
Any chance the default could be bumped for the 7.4 release?
Does it cause a significant performance issue?
--
Rod Taylor [EMAIL PROTECTED]
Rod Taylor [EMAIL PROTECTED] writes:
I just noticed that the OSDL benchmarks for PostgreSQL appear to require
PostgreSQL be compiled with INDEX_MAX_KEYS as 64 rather than the default
of 32.
Which one? I've been testing dbt3 here and not seen that.
Any chance the default could be bumped for
On Tue, 2003-07-01 at 01:25, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
I just noticed that the OSDL benchmarks for PostgreSQL appear to require
PostgreSQL be compiled with INDEX_MAX_KEYS as 64 rather than the default
of 32.
Which one? I've been testing dbt3 here and not seen
Rod Taylor wrote:
On Tue, 2003-07-01 at 01:25, Tom Lane wrote:
Not without evidence that it doesn't cause performance penalties.
ISTM we have been through this discussion recently, and concluded
that 32 was the place to set it.
Yes, I was digging through that discussion. The test used shows a 4%
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
So array[] should produce '{}' of (an array) type determined by the
context? OK -- seems easy enough.
Is it? I think we'd decided that this could only reasonably be handled
by creating a datatype representing array-of-UNKNOWN. I'm afraid to
Peter Eisentraut wrote:
* Using an array as a table source using UNNEST, something like:
select * from unnest(test.b);
(Check the exact spec to be sure; clause 7.6.)
select * from unnest(array['a','b']);
?column?
--
a
b
select * from unnest(array['a','b']) WITH ORDINALITY;
?column? |
A few days ago I have posted a pre-beta version of dblink_ora which is
supposed to solve some problems we had here at Cybertec (getting data
from an Oracle DB and merge it with PostgreSQL). I have implemented a
simple piece of code (more proof of concept than production).
Since I have not got
Hi, folks;
We're running Postgres 7.3.2 and we have a core dump on HP-11.
This does not seem reproducible on Solaris or Linux.
Working with debugger we get this stack:
#0 0xc0185a20 in mallinfo+0x2144 () from /usr/lib/libc.2
(gdb) where
#0 0xc0185a20 in mallinfo+0x2144 () from /usr/lib/libc.2
#1
Joe Conway wrote:
Bruce Momjian wrote:
OK, can you take ownership of it?
You mean a TODO entry? Sure, as long as Hans is OK with it.
Joe
I am ok with it.
The only problem I have at the moment is that I don't know how to build
properly and to check for the libs needed by Oracle.
The entire
Curious bit of synchronicity, related discussion going on in comp.arch
on same topic, lurkers like me might appreciate the explanation given in
http://groups.google.com/groups?selm=svudnRBY5twrXG6jXTWJkQ%40metrocast.net
---(end of broadcast)---
hi all,
i'm progressing with my implementation of ARC to try to replace LRU.
I have the following questions:
- When do we know we have a page fault ?
i've found AddBufferToFreelist() to be one. but are there other places as
well ?
- What variable holds the number of our cache capacity ?
i'm
ftp://ftp.kame.net/pub/kame/misc/
has IPv6 datatype patch (makes inet type handle both IPv4 and IPv6)
for 7.3.2. let me know how i can proceed/help.
There already is a patch in cvs head that does the same except it
doesn't handle the scope.
It would probably be useful to look
I was researching on cache replacement strategy as well. 2Q has one
disadvantage see this exellent paper:
http://www.almaden.ibm.com/cs/people/dmodha/#ARC see the paper
ARC: A Self-Tuning, Low Overhead Replacement Cache for theory and One
Up on LRU for implementation details. ARC requires no
For 7.4 (which I expect is the patch's target) it might be
best to make both names point to the same thing with a
clear release note that says that they are the same thing
and that plpython[u] is now untrusted.
That will give people a bit a time to reload their
existing functions.
elein
On
I thought there would be a relatively clear way
to alias them both to the same language library for
a release or two. But I see your point on transitioning.
Clear notice is really important.
plpython should be phased out if it is not replaced
within a release or two.
If only the change could
Excellent -- thanks so much for your help. I just tried the function
with the right arguments, and it worked just fine.
Yet more proof of named parameters being a good thing...
Reuven
---(end of broadcast)---
TIP 3: if posting/reading through
On 30 Jun 2003, Hannu Krosing wrote:
Tom Lane kirjutas E, 30.06.2003 kell 01:21:
Hannu Krosing [EMAIL PROTECTED] writes:
The version with patch which removes RExec (as Python 2.x is not
supporting it ) is the right thoing to do FOR PYTHON 2.X, but there is
no reason to remove safe
32 matches
Mail list logo
