Douglass book, though I probably missed it. Anyone got a link for me to
read to make it happen?
Hash opclass is 5-times simpler that btree one :)
CREATE FUNCTION citext_hash(mchar)
RETURNS int4
AS 'MODULE_PATHNAME'
LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT;
CREATE OPERATOR CLASS
A bit long - the summary is that intptr_t should probably be used,
assuming I understand the problem this thread is talking about:
Ken Camann wrote:
1. An object in memory can have size Size (= size_t). So its big
(maybe 8 bytes).
2. An index into the buffer containing that object has index
CREATE FUNCTION citext_hash(*citext*)
DEFAULT FOR TYPE *citext* USING hash AS
Oops, citext of course.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing
Hi,
[I've searched archives for the subject, but couldn't find a related
discussion. If there is any, sorry for duplication.]
We're migrating nearly a dozen of MSSQL servers of size ~100GiB per
cluster. For this purpose, we dump MSSQL data to COPY files using a Java
program. We have database
On 5/11/08, daveg [EMAIL PROTECTED] wrote:
Attached is a patch to add a commandline option to pg_dump to limit how long
pg_dump will wait for locks during startup.
My quick review:
- It does not seem important enough to waste a short option on.
Having only long option should be enough.
-
Tom Lane wrote:
OK, I've reproduced the test case locally. I believe that when you
say worse, you mean worse than 8.3, right? And you did tell me
offlist that you were testing with --enable-cassert. CVS HEAD has
very substantially greater cassert overhead because of the
randomize_memory
I'm inclined to think that we'd better turn that off by default,
since it's not looking like it's catching anything new.
Well at least it caught the bug that Mark was performance testing with a
--enable-cassert build :/
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
I'm using the nvl() function from the orafce package. It is defined as a
polymorphic function so its function signature is
nvl(anyelement, anyelement)
Now if I try to use the function in this very typical way
nvl(numeric_col, 0)
we get
ERROR: function nvl(numeric, integer) does not exist
Gregory Stark wrote:
Well at least it caught the bug that Mark was performance testing with a
--enable-cassert build :/
True ;) I appreciated that there would be some overhead, but I didn't
think it would be that much. This was mainly since I seem to remember
there was talk a while back of
to look into an idea I currently have I need (and implemented) a new
piece of memory that resides in (Postgres) shared memory. My data
structures are in place an the new database seems running fine. Even
under high load :-)
Since these data structures are for collecting information I was
2008/7/3 Simon Riggs [EMAIL PROTECTED]:
I'm using the nvl() function from the orafce package. It is defined as a
polymorphic function so its function signature is
nvl(anyelement, anyelement)
Now if I try to use the function in this very typical way
nvl(numeric_col, 0)
we get
ERROR:
On Thu, 2008-07-03 at 12:22 +0200, Pavel Stehule wrote:
2008/7/3 Simon Riggs [EMAIL PROTECTED]:
I'm using the nvl() function from the orafce package. It is defined as a
polymorphic function so its function signature is
nvl(anyelement, anyelement)
Now if I try to use the function in
Tom Lane napsal(a):
Gregory Stark [EMAIL PROTECTED] writes:
Out of curiosity, what is a user-defined collation? Are there SQL statements
to go around declaring what order code points should be sorted in? That seems
like it would be... quite tedious!
Hm, that's a good point. SQL99 has
Simon Riggs wrote:
I'm using the nvl() function from the orafce package. It is defined as a
polymorphic function so its function signature is
nvl(anyelement, anyelement)
Now if I try to use the function in this very typical way
nvl(numeric_col, 0)
we get
ERROR: function nvl(numeric,
Paul van den Bogaard wrote:
Since these data structures are for collecting information I was able to
create a new function that retrieves its information from these data
structures and returns them as a result from a query.
However this is too intrusive. Since everything is in shared memory
On Thu, 2008-07-03 at 14:11 +0300, Heikki Linnakangas wrote:
What I'd like it to do is to recognise that the 0 should be cast
implicitly to another datatype within the same family. I want and expect
nvl(char_column, 0)
to fail, but I expect the various numeric/integer types we have to
Am Donnerstag, 3. Juli 2008 schrieb Ken Camann:
Anyway, back to the immediate problem. What would probably make sense
to try as a first step is something like
#ifndef WIN64
typedef unsigned long Datum;/* XXX sizeof(long) = sizeof(void *) */
#else
typedef unsigned long long
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-07-03 at 14:11 +0300, Heikki Linnakangas wrote:
What I'd like it to do is to recognise that the 0 should be cast
implicitly to another datatype within the same family. I want and expect
nvl(char_column, 0)
to fail, but I expect the
On Thu, Jul 03, 2008 at 11:15:10AM +0300, Marko Kreen wrote:
On 5/11/08, daveg [EMAIL PROTECTED] wrote:
Attached is a patch to add a commandline option to pg_dump to limit how
long
pg_dump will wait for locks during startup.
My quick review:
- It does not seem important enough to
Hi guys,
I have been following the mailing list and reading the source code
for a little while, and was wandering if someone could fill in the
gaps for me. Does PostgresQL view updates and inserts performed in a
function as part of the same transaction or are they considered
separate
On Thu, 2008-07-03 at 13:54 +0100, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-07-03 at 14:11 +0300, Heikki Linnakangas wrote:
What I'd like it to do is to recognise that the 0 should be cast
implicitly to another datatype within the same family. I want
am Thu, dem 03.07.2008, um 23:15:33 +1000 mailte Aaron Spiteri folgendes:
Hi guys,
I have been following the mailing list and reading the source code
for a little while, and was wandering if someone could fill in the
gaps for me. Does PostgresQL view updates and inserts performed in a
On Thu, 2008-07-03 at 23:15 +1000, Aaron Spiteri wrote:
Inside foo there was a INSERT and UPDATE, and the INSERT failed but
the UPDATE succeeded would the UPDATE be rolled back?
Just to add to the other answers, if the INSERT is before the UPDATE in
the function, the function execution stops
Thanks for pointers, that has cleared a few things up for me.
On 03/07/2008, at 11:27 PM, Csaba Nagy wrote:
On Thu, 2008-07-03 at 23:15 +1000, Aaron Spiteri wrote:
Inside foo there was a INSERT and UPDATE, and the INSERT failed but
the UPDATE succeeded would the UPDATE be rolled back?
Just
--On Montag, Juni 30, 2008 18:47:33 -0400 Bruce Momjian [EMAIL PROTECTED]
wrote:
I'd like to implement them if we agree on them
Bernd, have you made any progress on this?
Here's a patch for this. I'll add it to the commit fest wiki page if it's
okay for you.
--
Thanks
Hi All, I am having an issue with a deadlock scenario in PostgreSQL 8.3.1I have
the following database postgres, what I do is create two tables t1 and t2 in
this database and I have the following fileds t1(a_id smallint, fn
character(20), ln character(20), rt smallint)t2( c_id smallint, c_name
On Thu, 2008-07-03 at 19:56 +0530, cinu wrote:
Could anyone please tell me where I am going wrong and if there is a
way I can get the same behaviour that I am getting while I am
executing the through psql prompt.
You're mistake is that you think a transaction is related to your
terminal, but
cinu [EMAIL PROTECTED] writes:
Could anyone please tell me where I am going wrong and if there is a way I can
get the same behaviour that I am getting while I am executing the through psql
prompt.
a) you might try hitting return occasionally in your email :)
b) you maybe need to put a SELECT
daveg [EMAIL PROTECTED] writes:
On Thu, Jul 03, 2008 at 11:15:10AM +0300, Marko Kreen wrote:
- The statement_timeout is set back with statement_timeout = default
Maybe it would be better to do = 0 here? Although such decision
would go outside the scope of the patch, I see no sense having
any
On Jul 2, 2008, at 22:14, Tom Lane wrote:
Note that this sort of stuff will mostly be fixed by pg_indent,
whether or not David does anything about it. But certainly
conforming to the project style to begin with will cause less
pain to reviewers' eyeballs.
Yeah, I'll change it. I'm JAPH, so
Gregory Stark [EMAIL PROTECTED] writes:
I think what you're suggesting is making integer and floating point constants
like 0 and 0.1 be treated as unknown or perhaps a different kind of unknown,
unknown integral type and unknown numeric type.
No, that would be a pretty dangerous way to go
On Jul 3, 2008, at 00:19, Teodor Sigaev wrote:
Hash opclass is 5-times simpler that btree one :)
CREATE FUNCTION citext_hash(mchar)
RETURNS int4
AS 'MODULE_PATHNAME'
LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT;
CREATE OPERATOR CLASS citext_ops
DEFAULT FOR TYPE mchar USING hash AS
Peter Eisentraut [EMAIL PROTECTED] writes:
Present us the actual problems as you discover them, and we will find a
solution. Right now we are just guessing.
There seems to be two problems that affect 64-bit POSIX systems too:
Well, 64-bit POSIX works just fine, so unless you can present an
David E. Wheeler wrote:
On Jul 3, 2008, at 00:19, Teodor Sigaev wrote:
Hash opclass is 5-times simpler that btree one :)
CREATE FUNCTION citext_hash(mchar)
RETURNS int4
AS 'MODULE_PATHNAME'
LANGUAGE C IMMUTABLE RETURNS NULL ON NULL INPUT;
CREATE OPERATOR CLASS citext_ops
DEFAULT FOR
Here is an updated version of the patch, with a debug_explain_min_duration
parameter to allow explaining of just slow-running queries. I've also
incorporated
a couple of Simon Riggs' suggestions for formatting the output better.
Do I need to post this to -patches, or is that now obsolete?
Tom Lane wrote:
To get a working WIN64 port it'd be necessary to go around and replace
long with size_t/ssize_t in the places where it matters --- but there
are not 450 of them, I don't think. And I'd advise not touching the
places that use int; that will just bloat the patch and make it harder
Hi,
I have a patch that I have been using to support postgresql's
notion of ident authentication when using unix domain sockets on
Solaris. This patch basically just adds support for using
getupeercred() on Solaris so unix sockets and ident auth works just
like it does on Linux and
What I'd be inclined to think about is making
check_generic_type_consistency and related functions allow the
arguments matched to ANYELEMENT to be of different actual types
so long as select_common_type could determine a unique type to
coerce them all to. It'd take some refactoring
On Thu, Jul 3, 2008 at 10:58 AM, Dean Rasheed [EMAIL PROTECTED] wrote:
Here is an updated version of the patch, with a debug_explain_min_duration
parameter to allow explaining of just slow-running queries. I've also
incorporated
a couple of Simon Riggs' suggestions for formatting the output
Garick Hamlin [EMAIL PROTECTED] writes:
I have a patch that I have been using to support postgresql's
notion of ident authentication when using unix domain sockets on
Solaris. This patch basically just adds support for using
getupeercred() on Solaris so unix sockets and ident auth
it concerns me that despite it being day 3 of the July commit fest,
people are still being advised to add new items to the wiki page.
To make the idea work, we need to stick to the rules we defined when
we came up with the concept - specifically, no new patches once the
fest begins!
So please -
On Thu, Jul 03, 2008 at 02:01:22PM -0400, Tom Lane wrote:
Garick Hamlin [EMAIL PROTECTED] writes:
I have a patch that I have been using to support postgresql's
notion of ident authentication when using unix domain sockets on
Solaris. This patch basically just adds support for using
On 7/3/08, Dave Page [EMAIL PROTECTED] wrote:
it concerns me that despite it being day 3 of the July commit fest,
people are still being advised to add new items to the wiki page.
To make the idea work, we need to stick to the rules we defined when
we came up with the concept -
On Thu, Jul 3, 2008 at 8:02 PM, Marko Kreen [EMAIL PROTECTED] wrote:
On 7/3/08, Dave Page [EMAIL PROTECTED] wrote:
it concerns me that despite it being day 3 of the July commit fest,
people are still being advised to add new items to the wiki page.
To make the idea work, we need to stick to
On Thu, 2008-07-03 at 20:06 +0100, Dave Page wrote:
On Thu, Jul 3, 2008 at 8:02 PM, Marko Kreen [EMAIL PROTECTED] wrote:
On 7/3/08, Dave Page [EMAIL PROTECTED] wrote:
it concerns me that despite it being day 3 of the July commit fest,
people are still being advised to add new items to
On Thu, Jul 3, 2008 at 2:44 PM, Dave Page [EMAIL PROTECTED] wrote:
it concerns me that despite it being day 3 of the July commit fest,
people are still being advised to add new items to the wiki page.
To make the idea work, we need to stick to the rules we defined when
we came up with the
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= [EMAIL PROTECTED] writes:
attached are two patches against HEAD. The smaller one is meant to be
commited - it adds some functions that manipulate double-linked lists,
namely inserting a new cell after or before another cell and swapping
two adjacent cells.
On Thu, Jul 3, 2008 at 12:44 PM, Dave Page [EMAIL PROTECTED] wrote:
it concerns me that despite it being day 3 of the July commit fest,
people are still being advised to add new items to the wiki page.
To make the idea work, we need to stick to the rules we defined when
we came up with the
On Thu, Jul 3, 2008 at 8:34 PM, Alex Hunsaker [EMAIL PROTECTED] wrote:
The one I advised be added (the Auto Explain patch) was posted on Mar
29, 2008 (http://archives.postgresql.org/pgsql-hackers/2008-03/msg01214.php),
re-posted the Jun 30th and then an updated patch today... It only
being
Does anyone else have any suggestions about what I can do to diagnose this?
Do I need to re-initdb or can I reasonably keep running with the existing db?
A
On Mon, Jun 30, 2008 at 7:20 PM, Andrew Hammond
[EMAIL PROTECTED] wrote:
On Fri, Jun 27, 2008 at 8:14 PM, Tom Lane [EMAIL PROTECTED]
On Thu, Jul 3, 2008 at 3:45 PM, Dave Page [EMAIL PROTECTED] wrote:
On Thu, Jul 3, 2008 at 8:34 PM, Alex Hunsaker [EMAIL PROTECTED] wrote:
The one I advised be added (the Auto Explain patch) was posted on Mar
29, 2008 (http://archives.postgresql.org/pgsql-hackers/2008-03/msg01214.php),
Andrew Hammond [EMAIL PROTECTED] writes:
Does anyone else have any suggestions about what I can do to diagnose this?
The whole thing is pretty mystifying, especially the ENOSPC write
failure on what seems like it couldn't have been a full disk.
Jun 27 15:54:31 qadb2 postgres[92519]: [44-1]
Merlin Moncure [EMAIL PROTECTED] writes:
Are you suggesting that omission of a patch on the 'fest' page means
that you are bumped from the fest?
No, if you had submitted the patch on time then the correct next step
is to get it added to the fest page; I don't think that should be
controversial.
On Thu, Jul 3, 2008 at 2:35 PM, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Hammond [EMAIL PROTECTED] writes:
Does anyone else have any suggestions about what I can do to diagnose this?
The whole thing is pretty mystifying, especially the ENOSPC write
failure on what seems like it couldn't have
On Thu, Jul 3, 2008 at 10:37 PM, Tom Lane [EMAIL PROTECTED] wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
Are you suggesting that omission of a patch on the 'fest' page means
that you are bumped from the fest?
No, if you had submitted the patch on time then the correct next step
is to get
Andrew Hammond [EMAIL PROTECTED] writes:
On Thu, Jul 3, 2008 at 2:35 PM, Tom Lane [EMAIL PROTECTED] wrote:
The whole thing is pretty mystifying, especially the ENOSPC write
failure on what seems like it couldn't have been a full disk.
Yes, I've passed along the task of explaining why PG
I just had this same problem.
Perhaps the wiki and http://git.postgresql.org/static/serviceinfo.html
should also be updated with the working (i.e. http) URL?
...Robert
On Thu, Jul 3, 2008 at 12:56 AM, Yoshiyuki Asaba [EMAIL PROTECTED] wrote:
Hi,
From: Abhijit Menon-Sen [EMAIL PROTECTED]
Bruce Momjian wrote:
We have come to agreement that there is no longer a need for a separate
'patches' email list --- the size of patches isn't a significant issue
anymore, and tracking threads between the patches and hackers lists is
confusing.
I propose we close the patches list and tell
Hi Everyone,
My first posting to the group..
I came from a mysql background (~7 years, small/mid database, about
55gig), where I could do SHOW FULL PROCESSLIST; to see all the queries
currently queued/running on the system. I found it a very useful feature.
The Postgres equivalent is
Dave Witt wrote:
..but Postgres only shows the first ~1000 chars from each queued/running
query. I know this is a long-standing issue (from reading other
posts/sites), but I'd like to throw in my vote for showing the entire
query, in some future version (easier said than done, I know).
On Thu, Jul 3, 2008 at 3:47 PM, Tom Lane [EMAIL PROTECTED] wrote:
Andrew Hammond [EMAIL PROTECTED] writes:
On Thu, Jul 3, 2008 at 2:35 PM, Tom Lane [EMAIL PROTECTED] wrote:
The whole thing is pretty mystifying, especially the ENOSPC write
failure on what seems like it couldn't have been a full
61 matches
Mail list logo
