Hmm, I'll give it a go when I'm back in the office, but bear
in mind this is a Mingw build on which debugging is nigh-on
impossible.
I use the Snapshot
http://prdownloads.sf.net/mingw/gdb-6.3-2.exe?download from sf.net.
It has some issues, but it is definitely useable.
Andreas
How much effort would it be to add EXPLAIN/EXPLAIN ANALYSE capability to
pl/pgsql functions?
what I mean, is either a special mode, where SELECT my_plpgsql_func()
would print all query plans instead or in addition to executing them, or
some way for EXPLAIN to pass some flags to functions so that
Zeugswetter Andreas ADI SD wrote:
Hmm, I'll give it a go when I'm back in the office, but bear
in mind this is a Mingw build on which debugging is nigh-on
impossible.
I use the Snapshot
http://prdownloads.sf.net/mingw/gdb-6.3-2.exe?download from sf.net.
It has some issues, but it is
ITAGAKI Takahiro wrote:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
We might want to call GetCheckpointProgress something
else, though. It doesn't return the amount of progress made, but rather
the amount of progress we should've made up to that point or we're in
danger of not completing the
On Thu, 2007-04-19 at 22:37 +0200, Florian G. Pflug wrote:
I believe I have discovered the following problem in pgsql 8.2 and HEAD,
concerning warm-standbys using WAL log shipping.
The problem is that after a crash, the master might complete incomplete
actions via rm_cleanup() - but since
Simon Riggs wrote:
On Thu, 2007-04-19 at 22:37 +0200, Florian G. Pflug wrote:
The problem is that after a crash, the master might complete incomplete
actions via rm_cleanup() - but since it won't wal-log those changes,
the slave won't know about this. This will at least prevent the creation
of
On Mon, 2007-04-23 at 11:01 +0300, Hannu Krosing wrote:
How much effort would it be to add EXPLAIN/EXPLAIN ANALYSE capability to
pl/pgsql functions?
what I mean, is either a special mode, where SELECT my_plpgsql_func()
would print all query plans instead or in addition to executing them, or
ITAGAKI Takahiro wrote:
Heikki Linnakangas [EMAIL PROTECTED] wrote:
If I'm reading the code correctly, DSM makes no attempt to keep the
chunks ordered by block number. If that's the case, vacuum needs to be
modified because it currently relies on the fact that blocks are scanned
and the dead
Gustavo Tonini wrote:
Well, I'm thinking in define (maybe via SQL) a set of servers as a
cluster and make the fragmentation rules based on select clauses,
storing this configuration in a specific catalog in global schema.
For example: when a record is inserted in a server which not store
this
Dave Page wrote:
If you want to poke at it, I'd suggest changing the ERROR to PANIC
(it's in bufmgr.c) to cause a core dump, run installchecks till you
get a panic, and then look around in the dump to see what you can find.
Well, in typical fashion after 25+ runs this morning there's not a
I don't insist the name and the default of the GUC parameter.
I'm afraid wal_fullpage_optimization = on (default) makes
some confusion because the default behavior becomes a bit
different on WAL itself.
Seems my wal_fullpage_optimization is not a good name if it caused
misinterpretation
Hi,
I was wondering if there is any possibility to add an enhancement in
pgAdmin Query.
Now, when we do select * from smth, results are listed in DataOutput
tab and there we have columns with the same width (something about
260px currently). It is realy annoying that in most cases user don't
see
Artur Wasilewski wrote:
Hi,
I was wondering if there is any possibility to add an enhancement in
pgAdmin Query.
Now, when we do select * from smth, results are listed in DataOutput
tab and there we have columns with the same width (something about
260px currently). It is realy annoying that in
If you have a table with a bunch of children, and these children all
have a primary key which is generated from the same sequence, assuming
that you're partitioning based on date (ie, this is a transaction
record table), it would be nice if the planner could spot that all
tables have a primary key
Andrew Hammond [EMAIL PROTECTED] writes:
If you have a table with a bunch of children, and these children all
have a primary key which is generated from the same sequence, assuming
that you're partitioning based on date (ie, this is a transaction
record table), it would be nice if the
On Tue, 2007-04-17 at 16:34 +0300, Marko Kreen wrote:
Attached patch does following conversions:
ISTM it would be cleaner to use an enum to identify the different
variants of the DISCARD command, rather than a character string.
Is guc.c still the logical place for the implementation of DISCARD?
How much effort would it be to add EXPLAIN/EXPLAIN ANALYSE capability to
pl/pgsql functions?
what I mean, is either a special mode, where SELECT my_plpgsql_func()
would print all query plans instead or in addition to executing them, or
some way for EXPLAIN to pass some flags to
Hackers,
I was thinking about the upcoming release on my 32-hour epic airplane ordeal,
and realizing that it changes PostgreSQL in a lot of ways. Between major
improvements to performance, major changes to the file format, and changes to
implicit conversions breaking backwards compatibility,
All,
You'll notice that the Hyena testing system for Solaris builds is down, due to
an attack and some required system upgrading. Since we'll have the new
Solaris machines up within a few days, I don't plan to revive Hyena's
Buildfarm instance. We're going to put some benchmark code on that
Josh Berkus wrote:
Between major
improvements to performance, major changes to the file format, and changes to
implicit conversions breaking backwards compatibility, our new ability to
more-or-less stick to deadlines ...
... should this be 9.0 instead of 8.3?
Seems like it'd be both an
While poking at Michel Dorochevsky's issue, I noticed that if a DELETE
is done in a table that is referenced by many different foreign keys,
we repeat the ri_Check_Pk_Match test over again for each FK. Seems like
it would be nice to avoid this duplicated work. But right now I don't
see any easy
On Sat, 2007-04-21 at 19:43 -0400, Neil Conway wrote:
Attached is a very quick hack of a patch to do this.
Does anyone have any feedback on this approach? If people are satisfied
with this solution, I can get a cleaned up patch ready to apply shortly.
-Neil
---(end of
So I was informed today that UNION types integer and text cannot be
matched. Alright, but it failed to tell which particular expressions
in this 3-branch, 30-columns-each UNION clause in a 100-line statement
it was talking about. So I made the attached patch to give some better
pointers.
Peter Eisentraut [EMAIL PROTECTED] writes:
peter=# values(0,1), (1::bigint,2), ('text'::text,3);
ERROR: 42804: VALUES types bigint at position 2 and text at position 3
cannot be matched in instance 1
I'm not sure about the terminology position and instance; they're
just two coordinates
In a PL/PgSQL set-returning function, returning the result set of a
query requires a FOR loop and repeated invocations of the RETURN NEXT
statement:
FOR x in SELECT ... LOOP
RETURN NEXT x;
END LOOP;
This works, but it seems overly verbose. It occurred to me that we could
easily
Neil,
This works, but it seems overly verbose. It occurred to me that we could
easily add a new PL/PgSQL statement that evaluates a set-returning
expression and adds *all* the resulting rows to the function's result
set. For example:
RETURN QUERY SELECT ...;
I'm not sure of the right
We were about to submit a patch to ECPG to improve the performance
of embedded SQL, when we discovered that PREPARE had quit working.
Background:
We have a benchmark for a very large customer that consists of several
hundred programs containing several thousand embedded SQL statements.
In a
Neil Conway [EMAIL PROTECTED] writes:
On Sat, 2007-04-21 at 19:43 -0400, Neil Conway wrote:
Attached is a very quick hack of a patch to do this.
Does anyone have any feedback on this approach? If people are satisfied
with this solution, I can get a cleaned up patch ready to apply shortly.
Hackers,
Writing lots of additional code simply to remove a parameter that
*might* be mis-interpreted doesn't sound useful to me, especially when
bugs may leak in that way. My take is that this is simple and useful
*and* we have it now; other ways don't yet exist, nor will they in time
for
Neil Conway [EMAIL PROTECTED] writes:
This works, but it seems overly verbose. It occurred to me that we could
easily add a new PL/PgSQL statement that evaluates a set-returning
expression and adds *all* the resulting rows to the function's result
set. For example:
I think we've got something
Peter Eisentraut [EMAIL PROTECTED] writes:
None of this will help if you have multiple unrelated clauses that
invoke select_common_type(), but that might be better handled using the
parser location mechanism.
+1 on using the parser location mechanism and avoiding the terminology
problem
Josh Berkus [EMAIL PROTECTED] writes:
... should this be 9.0 instead of 8.3?
No. This is mere version-number-inflation.
Eyeing the patch queue and wondering how much of it is really going to
get in, I'm not sure that eight point two and a half wouldn't be a more
appropriate name. It's been
Josh, List,
On 4/23/07, Josh Berkus [EMAIL PROTECTED] wrote:
Hackers,
I was thinking about the upcoming release on my 32-hour epic airplane ordeal,
and realizing that it changes PostgreSQL in a lot of ways. Between major
improvements to performance, major changes to the file format, and
On Mon, 2007-04-23 at 17:38 -0400, Tom Lane wrote:
I'm really still opposed to the entire concept. You're proposing to put
a lot of fragile-looking code into a seldom-exercised error path.
There's certainly not a lot of code: the patch just adds a few
syscache lookups, wrapped in a
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
This works, but it seems overly verbose. It occurred to me that we could
easily add a new PL/PgSQL statement that evaluates a set-returning
expression and adds *all* the resulting rows to the function's result
set. For example:
I
Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
peter=# values(0,1), (1::bigint,2), ('text'::text,3);
ERROR: 42804: VALUES types bigint at position 2 and text at
position 3 cannot be matched in instance 1
I'm not sure about the terminology position and instance;
Tom,
Eyeing the patch queue and wondering how much of it is really going to
get in, I'm not sure that eight point two and a half wouldn't be a more
appropriate name. It's been a short devel cycle and one almost entirely
focused on performance, not user-visible features.
Ah, in my enthusiasm
[EMAIL PROTECTED] escribió:
Josh, List,
On 4/23/07, Josh Berkus [EMAIL PROTECTED] wrote:
I was thinking about the upcoming release on my 32-hour epic airplane
ordeal,
and realizing that it changes PostgreSQL in a lot of ways. Between major
improvements to performance, major changes to
Tom Lane wrote:
+1 on using the parser location mechanism and avoiding the
terminology problem altogether.
I figured we would let the parser only point to the UNION or VALUES or
whatever word. It would be fairly cumbersome to drag the individual
expression positions down into
Neil Conway wrote:
On Mon, 2007-04-23 at 17:38 -0400, Tom Lane wrote:
I'm really still opposed to the entire concept. You're proposing to put
a lot of fragile-looking code into a seldom-exercised error path.
There's certainly not a lot of code: the patch just adds a few
syscache lookups,
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
+1 on using the parser location mechanism and avoiding the
terminology problem altogether.
I figured we would let the parser only point to the UNION or VALUES or
whatever word. It would be fairly cumbersome to drag the individual
Tom Lane wrote:
For the VALUES case, the suggestion of row and column terminology
seems the right thing, but for UNION it would be better to use branch
perhaps (row certainly seems misleading). How can we make that work
without indulging in untranslatable keyword-insertion?
Another
On 4/23/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Gustavo Tonini wrote:
Well, I'm thinking in define (maybe via SQL) a set of servers as a
cluster and make the fragmentation rules based on select clauses,
storing this configuration in a specific catalog in global schema.
For example:
Gustavo,
Oh, you're talking about distributing partitions across different nodes
and parallelizing queries. No, we don't do that today.
Yes.This is the goal. Well, I will try it. I'll send the project
reports to this list. Comments will be valuable. Desire me good
luck...
You might
Tom Lane [EMAIL PROTECTED] writes:
For the VALUES case, the suggestion of row and column terminology
seems the right thing, but for UNION it would be better to use branch
perhaps (row certainly seems misleading). How can we make that work
without indulging in untranslatable
On Monday 23 April 2007 18:17, Alvaro Herrera wrote:
That would be just because you don't know the numbering scheme. 8.2 to
8.3 is considered major in these parts. See
http://www.postgresql.org/support/versioning
Is that official policy? I don't see any mention of it in the docs.
--
Robert
Hi,
Sorry, because of so many comments/questions, I'll write inline
Josh Berkus wrote:
Hackers,
Writing lots of additional code simply to remove a parameter that
*might* be mis-interpreted doesn't sound useful to me, especially when
bugs may leak in that way. My take is that this is
The values of pg_enc enumeration are changed between 8.2 and 8.3.
PG_JOHAB was removed and PG_EUC_JIS_2004 was added.
Are there any incompatibility issues here?
For example, if we initialize a server(8.3) using initdb(8.3) and libpq(8.2)
with UTF-8 encoding, the server is actually initialized
Gregory Stark [EMAIL PROTECTED] writes:
The main data from the statistics that's of interest here are the extreme
values of the histogram. If we're not interested in any values in that range
then we can exclude the partition entirely.
Except that there is *no* guarantee that the histogram
That would be just because you don't know the numbering scheme. 8.2 to
8.3 is considered major in these parts. See
http://www.postgresql.org/support/versioning
Is that official policy? I don't see any mention of it in the docs.
Are you somehow suggesting that our website isn't
50 matches
Mail list logo
