I'm building an app where I have several entities that are identified
using a UUID (i.e. a 128 bit quantity). My current implementation uses a
composite primary key consisting of two int8 values. It's a bit
cumbersome and I would much rather have a distinct type. An earlier
implementation
On Wed, Jun 28, 2006 at 09:01:49AM +0200, Thomas Hallgren wrote:
I'm building an app where I have several entities that are identified
using a UUID (i.e. a 128 bit quantity). My current implementation uses a
composite primary key consisting of two int8 values. It's a bit
cumbersome and I
I end up calling this query quite often, so I need a way to speed it
up. Don't know if I can take advantage of indexes or better joins or
something (I don't even know if there are better joins), I'm really a
newbie to DB stuff. Hoping somebody can help me make this much
quicker.
EXPLAIN
On Wed, Jun 28, 2006 at 01:52:10AM -0600, Pat Maddox wrote:
I end up calling this query quite often, so I need a way to speed it
up. Don't know if I can take advantage of indexes or better joins or
something (I don't even know if there are better joins), I'm really a
newbie to DB stuff.
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 09:01:49AM +0200, Thomas Hallgren wrote:
I'm building an app where I have several entities that are identified
using a UUID (i.e. a 128 bit quantity). My current implementation uses a
composite primary key consisting of two int8 values.
On Wed, Jun 28, 2006 at 10:22:45AM +0200, Thomas Hallgren wrote:
Thanks. That would of course work but at the same time it increases the
complexity of my app. Yet another component to install and keep track
of. It's also a bit of an overkill since the only thing I need is an
opaque bit
How much I/O Performance do you need ?
READ Performance ? Write Performance ?
I need an fast and reliable RAID Controller (harddisks have to be hot plug,
automatic rebuild etc.)
and I have to say that the HP DL 380 G 4 with Battery Backup Write Cache ,
FAST U320 HDs,
some gigs ram (chipkill is a
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 10:22:45AM +0200, Thomas Hallgren wrote:
Thanks. That would of course work but at the same time it increases the
complexity of my app. Yet another component to install and keep track
of. It's also a bit of an overkill since the only thing I
On Tue, Jun 27, 2006 at 01:43:21PM +0200, Christian Rengstl wrote:
i am in the middle of breaking my head over designing a
database and came to the following question/problem: i have
persons whose values (integer) have to be entered in the db,
but per person the amount of values ranges from
On Wed, Jun 28, 2006 at 12:03:40PM +0200, Thomas Hallgren wrote:
OK. I thought you always had a type descriptor handy when reading the
binary representation. I've noticed that the typmod is expected in some
receive functions (bpcharrecv and numeric_recv for instance). Are you
saying that
dear all
we have the following issues and cannot start the
postgresql server:
postgresql 8.0.5
redhat EL WS4 U3
the computer was shutdown properly. then the user
restarted the computer, in the middle of rebooting, he
switched off the power button on the wall. after that
we cannot start the
Martijn van Oosterhout wrote:
On Wed, Jun 28, 2006 at 12:03:40PM +0200, Thomas Hallgren wrote:
OK. I thought you always had a type descriptor handy when reading the
binary representation. I've noticed that the typmod is expected in some
receive functions (bpcharrecv and numeric_recv for
Date and Pascal hate nulls. One even goes so far as to say that if you
permit NULLs in a database, then the results from *every* query is
suspect. So they turn perform backflips suggesting ways to avoid nulls.
None, so far, seem appealing.
To me, nulls are quite useful in the Real World. For
'Scuse my broken english and ungrammatical gibberish in my last
missive. That's what I get for posting before my first cup of coffee
for the day.
I'm serious about nulls though, and am wondering if Date and Pascal,
perhaps, are the gibberish ones on this particular issue. The
insistence on no
Thanks all for the reply.
Once pg_hba.conf is modified, do I have to run
pg_ctl reload ?
James
louis gonzales wrote:
James,
the psql command as you know is just the command line program that
requests connection to a database and depending how you issue the
command, determines if it's
Title: Re: [GENERAL] planning to upgrade to 8.1
i have 4 rpms
i first install
compat-postgresql-libs-3-3PGDG.i686.rpm
then i install
postgresql-libs-8.1.4-1PGDG.i686.rpm
the i install
postgresql-8.1.4-1PGDG.i686.rpm
herei get an error it says
failed dependency
librealdline.so.5 is
[EMAIL PROTECTED] wrote:
Date and Pascal hate nulls. One even goes so far as to say that if you
permit NULLs in a database, then the results from *every* query is
suspect. So they turn perform backflips suggesting ways to avoid nulls.
None, so far, seem appealing.
To me, nulls are quite useful
Hi,
On Wed, 2006-06-28 at 18:20 +0530, surabhi.ahuja wrote:
failed dependency librealdline.so.5 is needed by
postgresql-8.1.4-1PGDG.i686.rpm
yum install readline
Regards,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom
Florian G. Pflug wrote:
[EMAIL PROTECTED] wrote:
Date and Pascal hate nulls.
...the functions described by those functional dependencies are
not required to be defined for every possible value - let's say you have
a function dependency A - B - meaning that whenever you know the value
of
Berend Tober wrote:
Florian G. Pflug wrote:
[EMAIL PROTECTED] wrote:
Date and Pascal hate nulls.
...the functions described by those functional dependencies are
not required to be defined for every possible value - let's say you have
a function dependency A - B - meaning that
--- Berend Tober [EMAIL PROTECTED] wrote:
Florian G. Pflug wrote:
[EMAIL PROTECTED] wrote:
Date and Pascal hate nulls.
...the functions described by those functional
dependencies are
not required to be defined for every possible
value - let's say you have
a function
On Wed, Jun 28, 2006 at 01:56:47PM +0200, Thomas Hallgren wrote:
A user that is trusted with installing a C-function in the backend is
free to scan the process memory anyway so in what way did that increase
the security? IMHO, the only relevant security in that context is to
have trusted
--- Andrew Gould [EMAIL PROTECTED] wrote:
--- Berend Tober [EMAIL PROTECTED] wrote:
Florian G. Pflug wrote:
[EMAIL PROTECTED] wrote:
Date and Pascal hate nulls.
...the functions described by those functional
dependencies are
not required to be defined for every
Martijn van Oosterhout kleptog@svana.org writes:
The input functions get it, the output functions (bpcharout,
bpcharsend, etc) don't. Which makes it kind of hard to print a raw
value if you don't know how long it's going to be. They used to, but
that was removed some time back.
Even back then
On Wed, June 28, 2006 5:31 am, [EMAIL PROTECTED] wrote:
Date and Pascal hate nulls. One even goes so far as to say that if you
permit NULLs in a database, then the results from *every* query is suspect.
So they turn perform backflips suggesting ways to avoid nulls.
None, so far, seem
zhicheng wang [EMAIL PROTECTED] writes:
the computer was shutdown properly. then the user
restarted the computer, in the middle of rebooting, he
switched off the power button on the wall. after that
we cannot start the database server any more. the
following is the log. please help.
You can
On Wed, Jun 28, 2006 at 10:43:26AM -0400, A.M. wrote:
NULL is nothing more than a shortcut. SQL logic has to do backflips to
accomodate it- notice how NULL!=NULL- indeed, one NULL can mean a variety
of things even in the same context! (Bob doesn't know,HR doesn't
know,No one cares,Not
On Wed, Jun 28, 2006 at 02:31:20AM -0700, [EMAIL PROTECTED] wrote:
Date and Pascal hate nulls. One even goes so far as to say that if
you permit NULLs in a database, then the results from *every* query
is suspect. So they turn perform backflips suggesting ways to avoid
nulls. None, so far,
This reminds me of my favorite Bertrand Russell quote:
The difference between theory and practice is: in theory there is no
difference, but in practice, there is
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Florian G. Pflug
Sent: Wednesday, June 28,
On Wed, Jun 28, 2006 at 02:43:03AM -0700, [EMAIL PROTECTED] wrote:
'Scuse my broken english and ungrammatical gibberish in my last
missive. That's what I get for posting before my first cup of
coffee for the day.
I'm serious about nulls though, and am wondering if Date and Pascal,
perhaps,
On a tangent to the never-ending NULL debate, I've got a table:
CREATE TABLE events (
event_idINTEGER PRIMARY KEY,
tag_fk INTEGER REFERENCES tags (tag_id),
place_fkINTEGER REFERENCES places (place_id),
event_date CHAR(18) NOT NULL
On Wed, Jun 28, 2006 at 05:14:42PM +0200, Leif B. Kristensen wrote:
On a tangent to the never-ending NULL debate, I've got a table:
CREATE TABLE events (
event_idINTEGER PRIMARY KEY,
tag_fk INTEGER REFERENCES tags (tag_id),
place_fkINTEGER
On Fri, Jun 23, 2006 at 02:00:38PM -0400, Joseph Shraibman wrote:
I like to make sure the vacuum takes place during off peak times, which
is why I don't use autovacuum.
FWIW, now that there's vacuum_cost_delay that's usually not a very good
strategy. If you have anywhere close to enough load
On Sun, Jun 25, 2006 at 03:14:41PM -0400, brian ally wrote:
My question is, can i safely run my modifications again, but swap out
the INSERTs for the COPY WITH OIDs bit from the dump (adding my new
INSERTs after)? Would those OIDs still be good, so to speak?
Probably.
ANY advice
I'm trying to migrate a database cluster from one server to another. So I
did a pg_dumpall, ported everything over, yada yada yada.
I have one particular schema in one particular database that is giving me
trouble. All names for tables, sequences, functions, etc. are lowercase. I
repeat:
On Wednesday 28. June 2006 17:37, David Fetter wrote:
On Wed, Jun 28, 2006 at 05:14:42PM +0200, Leif B. Kristensen wrote:
On a tangent to the never-ending NULL debate, I've got a table:
CREATE TABLE events (
event_idINTEGER PRIMARY KEY,
tag_fk INTEGER
On Wed, Jun 28, 2006 at 09:02:04AM -0700, Bill Eaton wrote:
I'm trying to migrate a database cluster from one server to another. So I
did a pg_dumpall, ported everything over, yada yada yada.
I have one particular schema in one particular database that is giving me
trouble. All names for
I'm trying to migrate a database cluster from one server to
another. So I
did a pg_dumpall, ported everything over, yada yada yada.
I have one particular schema in one particular database that is
giving me
trouble. All names for tables, sequences, functions, etc. are
lowercase. I
I'm seeing something fairly unintuitive about serializable transactions.
Taking the following test case:
CREATE TABLE foo (id integer);
t1 t2
-- BEGIN;
-- SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
INSERT INTO foo (id) --
I have an insert/update/delete trigger on all my tables which add data
to a log table.
I would like to be able to disable them when the tables are called from
one stored proceedure I have. Yet I would still like those triggers to
fire on any other operation that is happening concurrently. Is
On Wed, Jun 28, 2006 at 02:48:01PM -0400, Brad Nicholson wrote:
I'm seeing something fairly unintuitive about serializable transactions.
Taking the following test case:
snip
http://www.postgresql.org/docs/8.1/interactive/transaction-iso.html
When a transaction is on the serializable
On Wed, Jun 28, 2006 at 06:25:22PM +0200, Leif B. Kristensen wrote:
event_date CHAR(18) NOT NULL DEFAULT
The event_date field is a fuzzy date construct. It will allow the
storage of such dates as 1784, ca. 1810, May 1852, 1798 or
1799, between 1820 and 1830 and so on. It's
self-replying with additional information
On Wed, Jun 28, 2006 at 09:33:18PM +0200, Karsten Hilbert wrote:
A full-blown implementation of a fuzzy timestamp type which
a) preserves the input/update timestamp
which tagged_types is able to handle
b) allows setting the accuracy of the value
On Wed, Jun 28, 2006 at 14:48:01 -0400,
Brad Nicholson [EMAIL PROTECTED] wrote:
I'm seeing something fairly unintuitive about serializable transactions.
When a transaction is on the serializable level, a SELECT query sees
only data committed before the transaction began; it never sees
On Wednesday 28. June 2006 21:33, Karsten Hilbert wrote:
On Wed, Jun 28, 2006 at 06:25:22PM +0200, Leif B. Kristensen wrote:
event_date CHAR(18) NOT NULL DEFAULT
The event_date field is a fuzzy date construct. It will allow the
storage of such dates as 1784, ca. 1810, May 1852,
Bill Eaton [EMAIL PROTECTED] writes:
Oops. That's a detail I left out. I can only reproduce this problem so far
in PGAdmin. I couldn't reproduce the error in psql or in a linked table in
MSAccess.
Turn on query logging so you can see exactly what query PGAdmin is
issuing to provoke the error.
Martijn van Oosterhout kleptog@svana.org writes:
I think the issue here is that transaction begin is not when you type
begin but at your first actual query. You can obviously only start a
transaction once you know what serialisation level you want, and you
don't see that till after the begin.
Oops. That's a detail I left out. I can only reproduce this
problem so far
in PGAdmin. I couldn't reproduce the error in psql or in a
linked table in
MSAccess.
Turn on query logging so you can see exactly what query PGAdmin is
issuing to provoke the error. There isn't any magic in
48 matches
Mail list logo
