On Thu, Jan 08, 2004 at 06:28:14AM -0500, Dave Smith wrote:
> Firstly you should always provide an explain from your query before
> posting to this list.
You mean "while posting", because he can't possible provide the explain
before having the means to do so, can he? :-)
> I think the problem is
I could not find any discussion on this but imho this seems an erroneous
error occuring now in 7.3.4 (after upgrade from 7.2.3):
select null::time, 'test'::varchar as time order by time;
ERROR: ORDER BY 'time' is ambiguous
The solution is to name the time datatype e.g.
select null::time as xy
"Paul Janssen" <[EMAIL PROTECTED]> writes:
> Can anyone help me out with the following situation:
>(a) a single query with 550 id's in the IN-clause resulting into 800+
> seconds;
>(b) 550 queries with a single id in the IN-clause resulting into overall
> time of <60 seconds;
> The table
Holger Marzen <[EMAIL PROTECTED]> writes:
> When I try to compile PostgreSQL 7.2.4 or 7.4.1 then I get
> |gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
> |-I../../../src/include -D_GNU_SOURCE -c hba.c -o hba.o
> |hba.c: In function `parse_hba':
> |hba.c:675: warning: implicit declar
Travel Jadoo <[EMAIL PROTECTED]> writes:
> I could not find any discussion on this but imho this seems an erroneous
> error occuring now in 7.3.4 (after upgrade from 7.2.3):
> select null::time, 'test'::varchar as time order by time;
> ERROR: ORDER BY 'time' is ambiguous
What's erroneous about
Hi,
I'm using version 7.3.3. I do a lot of modification to some of the tables in my database. There's a table that I didn't run vacuum on for a while and I ran some big queries on it. It was taking a long time so I aborted the query and tried running a vacuum on the table. It ran for around 48 hou
On Thu, 8 Jan 2004, Eric Freeman wrote:
>
> Hi,
>
> I'm using version 7.3.3. I do a lot of modification to some of the
> tables in my database. There's a table that I didn't run vacuum on for a
> while and I ran some big queries on it. It was taking a long time so I
> aborted the query and tried r
I'm trying to drop a table and it's taking a very long time. There has been
a lot of modification to the table and it has a lot of old data still being
used as a result of not using the vacuum function enough. I ran an insert
into and it was taking a long time (ran for about 48 hours) so I abort
On Thursday 08 January 2004 16:15, Eric Freeman wrote:
Please try not to post in html
> I'm using version 7.3.3. I do a lot of modification to some of the
> tables in my database. There's a table that I didn't run vacuum on for a
> while and I ran some big queries on it. It was taking a long time
"Eric Freeman" <[EMAIL PROTECTED]> writes:
> I started the drop table command yesterday and it's been running for almost
> 24 hours.
You're stuck in some kind of infinite loop --- there's no way that DROP
should take any noticeable amount of time. I'm guessing that the system
catalog entries for
Tom Lane wrote:
"Eric Freeman" <[EMAIL PROTECTED]> writes:
I started the drop table command yesterday and it's been running for almost
24 hours.
You're stuck in some kind of infinite loop --- there's no way that DROP
should take any noticeable amount of time. I'm guessing that the system
On Thu, 2004-01-08 at 16:09, Tom Lane wrote:
> Travel Jadoo <[EMAIL PROTECTED]> writes:
> > I could not find any discussion on this but imho this seems an erroneous
> > error occuring now in 7.3.4 (after upgrade from 7.2.3):
>
> > select null::time, 'test'::varchar as time order by time;
> > ERRO
Mike Mascari <[EMAIL PROTECTED]> writes:
> Is there any possibility that he's got an open transacation sitting out
> there for days holding a lock on that table?
Good thought ... but if that was the issue then the DROP would just be
sleeping waiting for the lock, and Eric did say it was consuming
Dear All,
I have some c code that writes results directly to a file as they're
produced during a simulation. I want to modify the code to write
directly to a postgres database using libpq. I think I could open a
connection and insert into the database with a transaction, commiting at
the end of th
Sorry, what's to keep you from increasing the max number of connections?
On Thu, 8 Jan 2004, C G wrote:
> Dear All,
>
> I have some c code that writes results directly to a file as they're
> produced during a simulation. I want to modify the code to write
> directly to a postgres database using
Hello
Iam play with SRF function and found difference between behavior system
function pg_stat_get_backend_idset and own function in plpgsql;
aopk=> \df pg_stat_get_backend_idset
Datový typ výsledku | Schéma | Jméno | Datový typ
parametru
-+-
Title: Message
Hi,
I need to know if
there is a way to defer or disable a unique index on a table during an
update. One way would be to set indisunique to false, perform update and then
set to true. But, this seems to be an ugly solution.
I've posted a similar message 6 months ago and at
I notice that 7.4 doesn't do default ordering on a 'group by', so you have
to throw in an 'order by' clause to get the output in ascending group order.
Is this something that most RDB's have historically done (including PG prior
to 7.4) but isn't really part of the SQL standard?
On a mostly
> Hmm but the first one has actually no name, it's just casted as datatype
> time. I now realise that casted columns get assigned the datatype as
> name. Should it not show ?column? as output just like you a "select
> null;" would do?
i think you're confusing what the front end uses as a default
On Thu, 8 Jan 2004, Tom Lane wrote:
> Holger Marzen <[EMAIL PROTECTED]> writes:
> > When I try to compile PostgreSQL 7.2.4 or 7.4.1 then I get
>
> > |gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
> > |-I../../../src/include -D_GNU_SOURCE -c hba.c -o hba.o
> > |hba.c: In function `pa
On Thu, Jan 08, 2004 at 13:42:33 -0600,
Mike Nolan <[EMAIL PROTECTED]> wrote:
> I notice that 7.4 doesn't do default ordering on a 'group by', so you have
> to throw in an 'order by' clause to get the output in ascending group order.
>
> Is this something that most RDB's have historically done
In Interbase and Firebird, NUMERIC is implemented as 64-bit integer.
This limits the range to NUMERIC(18, *) but for many uses that's
adequate. And moreover it's fast and efficient.
Is there a way in PostgreSQL to do something similar, i.e. I want to:
- use 64-bit ints, not string bits or arbit
On Tue, Jan 06, 2004 at 10:50:57 -,
Daryl Shanley <[EMAIL PROTECTED]> wrote:
> I have some c code that writes results directly to a file as they're
> produced during a simulation. I want to modify the code to write
> directly to a postgres database using libpq. I think I could open a
> connec
"D. Dante Lorenso" <[EMAIL PROTECTED]> writes:
> Is there going to be a RedHat 10? Or are we all supposed
> to choose a path of RH Enterprise vs Fedora Core?
The current plans do not include a Red Hat 10 --- Enterprise and Fedora
are it.
Now, I have been working for Red Hat long enough to know t
On Thu, Jan 08, 2004 at 15:24:41 -0800,
Ron St-Pierre <[EMAIL PROTECTED]> wrote:
> Celko uses the SQL92 13.1 rule wording: "Whether a sort key value that
> is NULL is considered greater or less than a non-NULL value is
> implementation defined, but all sort key values that are NULL will
> eith
> connection failed :(
>
> Dave
I had no problem accessing it - very nice and responsive ! Great job Oleg
and Teodor.
-- Glenn
- Original Message -
From: "Dave Cramer" <[EMAIL PROTECTED]>
To: "Oleg Bartunov" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Pgsql Hackers"
<[EMAIL PROTECT
26 matches
Mail list logo
