Michael Fuhr <[EMAIL PROTECTED]> writes:
> The problem appears to be that proargtypes[0] is now NULL instead
> of 0. Here's a simplified version of the \df query:
> SELECT proname
> FROM pg_catalog.pg_proc p
> WHERE p.proargtypes[0] <> 'pg_catalog.cstring'::pg_catalog.regtype
> AND p.pr
In HEAD psql, \df doesn't show functions that have no arguments:
test=> CREATE FUNCTION foo() RETURNS integer AS 'SELECT 1' LANGUAGE sql;
CREATE FUNCTION
test=> \df foo
List of functions
Schema | Name | Result data type | Argument data types
+--+---
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> We have a problem as soon as somebody tries to delete a lot of rows from
> a big table. We cannot possibly extend the memory requirements forever,
> so we need to spill to disk without having an in-shared-memory index.
Yes. I'm not sure that I see the
Neil Conway <[EMAIL PROTECTED]> writes:
> I think this tweak would be universally better than the existing code.
Yes, but you miss the point: there's a case where the existing code
isn't good and you aren't improving it. Specifically, where the inner
query has high startup cost and the outer quer
Tom Lane wrote:
One small objection is that we'd lose the ability to separately display
the time spent building the hash table in EXPLAIN ANALYZE output. It's
probably not super important, but might be a reason to keep two plan
nodes in the tree.
Hmm, true. Perhaps then just hacking the hash node
One small objection is that we'd lose the ability to separately display
the time spent building the hash table in EXPLAIN ANALYZE output. It's
probably not super important, but might be a reason to keep two plan
nodes in the tree.
Would a separate hash node help for these kinds of queries in the f
Neil Conway <[EMAIL PROTECTED]> writes:
> ... I'm wondering if there is any value to maintaining the hash
> vs. hash join distinction in the first place.)
One small objection is that we'd lose the ability to separately display
the time spent building the hash table in EXPLAIN ANALYZE output. It's
Is there a reason why the implementation of hash joins uses a separate
"hash" child node? AFAICS that node is only used in hash joins. Perhaps
the intent was to be able to provide a generic "hashing" capability that
could be used by any part of the executor that needs to hash tuples, but
AFAICS
I see this in my PQA analyzed PostgreSQL log:
Slowest queries
select dict_init, dict_initoption, dict_lexize from pg_ts_dict where oid
= $1
It's my number one slowest query apparently!
Can that lookup perhaps be cached in some way?
I notice that there is no unique index on the oid column
On Tue, 29 Mar 2005 20:46:44 +0900, 윤동수 <[EMAIL PROTECTED]> wrote:
> I 'll use a bound cursor with parameters.
> But when I use such a cursor, I found a error.
> I don't know error message.
>
How do you know there is an error. Postgres should send you a message
or a log entry. without it i doubt ca
Neil Conway <[EMAIL PROTECTED]> writes:
> I'd like to make add_missing_from=false the default for 8.1. Any objections?
We still don't have a solution for DELETE, do we?
regards, tom lane
---(end of broadcast)---
TIP 9: the p
I'd like to make add_missing_from=false the default for 8.1. Any objections?
I think the only reason not to do this is for backward compatibility
with previous releases of PostgreSQL, but I don't find that too
compelling: it is easy to fix up queries that rely on the old behavior,
and the old be
Hackers,
I'm seeing what can I do about spilling the lock table to disk
I welcome comments on the ideas outlined here. If anyone sees a
showstopper please let me know.
Notes on Spilling the Lock Table to Disk
The problem being solved here is the inherent
Andrew Dunstan wrote:
> [andrew pgsql]$ LC_ALL=en_US.UTF-8 locale charmap
> UTF-8
That seems normal. Time to get out the debugger, I suppose.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 5: Have you ch
Peter Eisentraut wrote:
Andrew Dunstan wrote:
The database cluster will be initialized with locale en_US.UTF-8.
initdb: could not find suitable encoding for locale "en_US.UTF-8"
What does
$ LC_ALL=en_US.UTF-8 locale charmap
show?
[andrew pgsql]$ LC_ALL=en_US.UTF-8 locale charmap
UTF-8
[
Palle Girgensohn wrote:
> Just a comment: ORDER BY *is* already case sensitive on Linux, since
> its strcoll ignores case. I doubt very much it violates SQL
> standards.
The behavior of collation sequences is implementation-defined. So as
long as you can put the behavior in words, it should be O
Andrew Dunstan wrote:
> The database cluster will be initialized with locale en_US.UTF-8.
> initdb: could not find suitable encoding for locale "en_US.UTF-8"
What does
$ LC_ALL=en_US.UTF-8 locale charmap
show?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
--
Jim Buttafuoco wrote:
I can confirm that the latest cygwin snapshot (cygwin1-20050328.dll) corrects
the stats regression failure.
Yes, it does for me too. Thanks
andrew
---(end of broadcast)---
TIP 8: explain analyze is your friend
--On Mittwoch, März 30, 2005 11:35:05 -0400 Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
On Tue, Mar 29, 2005 at 07:30:13PM +0200, Bernd Helmle wrote:
Well, the patch is far away from being ready for -patches, but if you
want to "preview" you can get our latest patch against HEAD at
http://www.oops
On Tue, Mar 29, 2005 at 07:30:13PM +0200, Bernd Helmle wrote:
> Well, the patch is far away from being ready for -patches, but if you want
> to "preview" you can get our latest patch against HEAD at
>
> http://www.oopsware.de/pgsql_viewupdate.html
Well, that description there says what the patc
Hey folks,
Sorry to post with this (slightly) off topic message,
but just wanted to get the word out.
Bruce and Jan will be presenting on Postgresql April
16th at Penn State Great Valley in Malvern, PA. The
event is sponsored by the company I work for, Chariot
Solutions. It's completely free a
Andrew,
I can confirm that the latest cygwin snapshot (cygwin1-20050328.dll) corrects
the stats regression failure.
Jim
-- Original Message ---
From: Andrew Dunstan <[EMAIL PROTECTED]>
To: Tom Lane <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], pgsql-hackers@postgresql.org
Sent: W
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I'm not quite sure what question I should be asking of the Cygwin people.
Tom, Can you suggest something?
It sounds to me like the problem is that the backend executing the test
script is in a tight loop (due to the half-baked im
23 matches
Mail list logo
