On Sun, 2007-11-25 at 19:35 -0500, Tom Lane wrote:
The cost of resolving ambiguous operators has been an issue for a long
time, of course, but it seems particularly bad in this case --- gprof
blames 37% of the runtime on oper_select_candidate(). It might be time
to think about caching the
On 11/10/07, Tom Lane [EMAIL PROTECTED] wrote:
The current plpgsql code seems to be designed to force a qualifier to be
interpreted as a block label if at all possible, even if there are
more-closely-nested alternative interpretations; so in the above example
it would assign to the outer
On Thu, 2007-11-22 at 21:59 -0500, Christopher Browne wrote:
The world rejoiced as [EMAIL PROTECTED] (Alvaro Herrera) wrote:
Simon Riggs wrote:
I notice that slony records the oldestxmin that was running when it last
ran a VACUUM on its tables. This allows slony to avoid running a VACUUM
Am Samstag, 24. November 2007 schrieb Simon Riggs:
In many cases, 100% of queries are unprepared.
I have seen many applications where prepared queries caused stale plans and
poor performance. We have in many cases achieved great performance gains by
turning off prepared queries globally, for
On Nov 26, 2007 11:59 AM, Peter Eisentraut [EMAIL PROTECTED] wrote:
I have seen many applications where prepared queries caused stale plans and
poor performance. We have in many cases achieved great performance gains by
turning off prepared queries globally, for example in the driver layer.
Simon Riggs wrote:
On Thu, 2007-11-22 at 21:59 -0500, Christopher Browne wrote:
I imagine it might be useful to add it to autovac, too. I thought it
was pretty neat that this could be successfully handled by comparison
with a single value (e.g. - eldest xmin), and I expect that using a
Hi to all.
I'm new. I'd like to integrate my code into PostgreSQL. It's the
implementation of some refinements of Replacement Selection algorithm used
for External Sorting.
I have got some issue and preferibly I'd like to be supported by some
developers that have something to do with it.
Am Samstag, 24. November 2007 schrieb Bruce Momjian:
Peter, were you going to address this?
It's done now.
diff -ur ../cvs-pgsql/configure.in ./configure.in
--- ../cvs-pgsql/configure.in 2007-11-16 21:25:10.0 +0100
+++ ./configure.in 2007-11-16 22:27:36.0 +0100
@@
[EMAIL PROTECTED] wrote:
I'm new. I'd like to integrate my code into PostgreSQL. It's the
implementation of some refinements of Replacement Selection algorithm
used for External Sorting.
I have got some issue and preferibly I'd like to be supported by some
developers that have something to do
Am Freitag, 23. November 2007 schrieb Tom Lane:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Should we force initdb to correct these pg_proc entries, or just quietly
change pg_proc.h?
Considering the extent of the changes, I'd be in favor of forcing an
initdb.
Well, if
Thanks for your support.
I downloaded the source code of the last stable version of PostgreSQL. Where
can I find the part related to the External Sorting algorithm (supposed to
be Replacement Selection)?
I mean, which is the file to be studied and/or modified and/or substituted?
Thanks for
[EMAIL PROTECTED] wrote:
Thanks for your support.
I downloaded the source code of the last stable version of PostgreSQL.
Where can I find the part related to the External Sorting algorithm
(supposed to be Replacement Selection)?
I mean, which is the file to be studied and/or modified
[EMAIL PROTECTED] wrote:
I downloaded the source code of the last stable version of PostgreSQL.
Where can I find the part related to the External Sorting algorithm
(supposed to be Replacement Selection)?
I mean, which is the file to be studied and/or modified and/or substituted?
In
Hi everyone,
I'm working on a piece of code for PostGIS to allow the loading of
projection configuration files from the share/postgresql directory, but
I can't find a way of getting this to work under Win32.
AIUI the way to do this would be to use a combination of my_exec_path
and get_share_path
Simon Riggs [EMAIL PROTECTED] writes:
But I think there must be an action that we can take for 8.3 and that
much runtime should not be given away easily. ISTM that we can win back
the losses Guillaume has identified, plus gain a little more even.
Perhaps some sanity could be restored to this
Peter Eisentraut [EMAIL PROTECTED] writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, if you're going to change the contents of pg_cast then there is
little choice. I was considering something less invasive ...
I will hang on to this patch for a few more days to see if
Marko Kreen [EMAIL PROTECTED] writes:
On 11/10/07, Tom Lane [EMAIL PROTECTED] wrote:
Can anyone comment on how Oracle handles cases like this?
Some googling brought following link:
http://download-uk.oracle.com/docs/cd/B14117_01/appdev.101/b10807/d_names.htm
Hmm, interesting document. I
Hello
I propose new kind of FOR statement .. iteration over cursor, There
are two reasons:
a) better readability of procedure; - SQL statement is outside of statement,
b) better conformance with PL/SQL.
Sample:
CREATE OR REPLACE FUNCTION foo()
RETURNS void AS $$
DECLARE
c CURSOR(p integer)
Ok guys!
Thanks for your help.
Unfortunately I'm lost into the code... any good soul helping me to
understand what should be the precise part to be modified?
Thanks for your time!
--
From: Heikki Linnakangas [EMAIL PROTECTED]
Sent: Monday,
Pavel Stehule [EMAIL PROTECTED] writes:
I propose new kind of FOR statement .. iteration over cursor,
This seems useless and probably syntactically ambiguous.
regards, tom lane
---(end of broadcast)---
TIP 1: if
Am Montag, 26. November 2007 schrieb Tom Lane:
Pavel Stehule [EMAIL PROTECTED] writes:
I propose new kind of FOR statement .. iteration over cursor,
This seems useless and probably syntactically ambiguous.
I think that is isomorphic to what he mentioned as better conformance with
PL/SQL.
Am Montag, 26. November 2007 schrieb Mark Cave-Ayland:
I'm working on a piece of code for PostGIS to allow the loading of
projection configuration files from the share/postgresql directory, but
The share directory is the wrong place for configuration files anyway. And
moreover, non-PostgreSQL
[EMAIL PROTECTED] wrote:
Unfortunately I'm lost into the code... any good soul helping me to
understand what should be the precise part to be modified?
You haven't given any details on what you're trying to do. What are you
trying to do?
--
Heikki Linnakangas
EnterpriseDB
[EMAIL PROTECTED] wrote:
Ok guys!
Thanks for your help.
Unfortunately I'm lost into the code... any good soul helping me to
understand what should be the precise part to be modified?
I think you should print the file and read it several times until you
understand what's going on. Then you
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 26. November 2007 schrieb Mark Cave-Ayland:
I'm working on a piece of code for PostGIS to allow the loading of
projection configuration files from the share/postgresql directory, but
The share directory is the wrong place for configuration
On Mon, 2007-11-26 at 09:55 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
But I think there must be an action that we can take for 8.3 and that
much runtime should not be given away easily. ISTM that we can win back
the losses Guillaume has identified, plus gain a little more
Alvaro Herrera [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Unfortunately I'm lost into the code... any good soul helping me to
understand what should be the precise part to be modified?
I think you should print the file and read it several times until you
understand what's going on.
Peter Eisentraut wrote:
Am Montag, 26. November 2007 schrieb Mark Cave-Ayland:
I'm working on a piece of code for PostGIS to allow the loading of
projection configuration files from the share/postgresql directory, but
The share directory is the wrong place for configuration files anyway.
On 26/11/2007, Tom Lane [EMAIL PROTECTED] wrote:
Pavel Stehule [EMAIL PROTECTED] writes:
I propose new kind of FOR statement .. iteration over cursor,
This seems useless and probably syntactically ambiguous.
I don't see any syntactically problem and I have working prototype.
This case is
On Nov 26, 2007 5:58 PM, Simon Riggs [EMAIL PROTECTED] wrote:
I've written up my suggestion as a 5 line patch, with measured
performance improvement of about 40% for the varchar case.
It isn't a great long term fix, but I don't want to delay 8.3 either
with the full fix.
Can we see the
Thanks for your advice.
The developement of this integration is part of my final project. And fo
course my initial bibliografy includes the Knuth reference as you can see
1. Vladimir Estivill-Castro and Derick Wood. A survey of adaptive sorting
algorithms. ACM Computing Surveys, 24(4):441{476,
While supporting a customer to increase recovery performance from its
backups i just realized that PostgreSQL never uses big maintenance_work_mem
settings. Even giving 10GB of RAM to maintenance_work_mem results in using
a fraction of memory (it switches to external sort after using around 2
Simon Riggs [EMAIL PROTECTED] writes:
I've written up my suggestion as a 5 line patch, with measured
performance improvement of about 40% for the varchar case.
A 5-line patch which improves performance by 40% for any case sounds amazing,
but how fragile is that gain? The kind of thing which
Gregory Stark [EMAIL PROTECTED] writes:
A 5-line patch which improves performance by 40% for any case sounds amazing,
but how fragile is that gain? The kind of thing which would be worryign is if
runing a query which uses both varchar and some other ambiguous operator
causes it to lose all its
Bernd Helmle [EMAIL PROTECTED] writes:
... But isn't it worth to special case the
code in grow_memtuples() (and maybe other places where sort is likely to
use more RAM), so that we can remove this constraint on 64-Bit systems with
many RAM built in? Or am I missing something very
Sorry.
I'm trying to integrate my code into PostgreSQL. At the moment I have got my
working code, with my own main() etc etc.
The code is supposed to perform run generation during external sorting.
That's all, my code won't do any mergesort. Just run generation.
I'm studing the code and I
[EMAIL PROTECTED] (Peter Eisentraut) writes:
Am Montag, 26. November 2007 schrieb Tom Lane:
Pavel Stehule [EMAIL PROTECTED] writes:
I propose new kind of FOR statement .. iteration over cursor,
This seems useless and probably syntactically ambiguous.
I think that is isomorphic to what he
[EMAIL PROTECTED] writes:
3) Start run generation. As for this phase, I see PostgreSQL code (as Knuth
algorithm) marks elements belonging to runs in otder to know which run they
belong to and to know when the current heap has finished building the
current run. I don't memorize this kind of
I must precise that it's not the improvement. Other more complex algorithms
correspond to the refinements, but at the moment I just want to know which
part of PostgreSQL code does what. I also implemented Replacement Selection
(RS) so if I'm able to integrate my RS I hope I would be able to
On Nov 26, 2007 6:48 PM, Tom Lane [EMAIL PROTECTED] wrote:
In the test case Guillame provided, every single WHERE clause happens
to be of the form
varchar_column = 'unknown-type literal'
and there are no other operators used in the SELECT lists; but I can
hardly believe that this is
[EMAIL PROTECTED] wrote:
I also implemented
Replacement Selection (RS) so if I'm able to integrate my RS I hope I
would be able to integrate the others too.
The existing code implements RS. Tom asked you to describe what improvements
you hope to make; I'm confident that he already
On Mon, Nov 26, 2007 at 1:04 PM, in message
[EMAIL PROTECTED], Guillaume Smet
[EMAIL PROTECTED] wrote:
On Nov 26, 2007 6:48 PM, Tom Lane [EMAIL PROTECTED] wrote:
In the test case Guillame provided, every single WHERE clause happens
to be of the form
varchar_column = 'unknown-type
Dave Page wrote:
How does that work with the stuff that goes into directories relative to
$libdir (per documented recommendations), without creating easy-to-break
paths like $libdir/../../MyAddon/8.3/MyAddon.dll?
Which documented recommendation do you speak of?
--
Peter Eisentraut
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Montag, 26. November 2007 schrieb Mark Cave-Ayland:
I'm working on a piece of code for PostGIS to allow the loading of
projection configuration files from the share/postgresql directory, but
The share directory is the wrong
--On Montag, November 26, 2007 13:02:14 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
... But isn't it worth to special case the
code in grow_memtuples() (and maybe other places where sort is likely to
use more RAM), so that we can remove this constraint on
Quoting Tom, from the previous thread linked by Martijn:
It could be pretty ugly, because type assignment normally proceeds
bottom-up :-(. What you might have to do is make the raw grammar
representation of ARRAY[] work like A_Const does, ie, there's a
slot to plug in a typecast. That's
--- Original Message ---
From: Peter Eisentraut [EMAIL PROTECTED]
To: Dave Page [EMAIL PROTECTED]
Sent: 26/11/07, 20:14:25
Subject: Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
Dave Page wrote:
How does that work with the stuff that goes into directories relative to
Brendan Jurd [EMAIL PROTECTED] writes:
This approach is making sense to me, but I've run into a bit of a
dependency issue. A_Const does indeed have a slot for typecasts by
way of a TypeName member. A_Const and TypeName are both defined in
parsenodes.h, whereas ArrayExpr is defined in
Dave Page [EMAIL PROTECTED] writes:
From: Peter Eisentraut [EMAIL PROTECTED]
Which documented recommendation do you speak of?
http://www.postgresql.org/docs/8.3/static/xfunc-c.html states:
It is recommended to locate shared libraries either relative to $libdir or
through the dynamic library
Kevin Grittner [EMAIL PROTECTED] writes:
Are we likely to see the 3% or the 7% performance degradation with
version 8.3?
Probably not, since it sounds like your queries are typically not as
trivial as the ones in Guillame's test case. IOW there will be some
slowdown but it's likely to be in
[EMAIL PROTECTED] writes:
Anyway, even in my RS implementation a longer run is created. The first M
initialization elements will surely form part of the current run. M is the
memory size so at least a run sized M will be created. After initialization,
the elements are not suddenly output,
On Mon, 2007-11-26 at 11:55 -0500, Tom Lane wrote:
I'm not sure why Mark's having a problem accessing my_exec_path ---
it *is* declared DLLIMPORT in miscadmin.h (which is where it counts,
AIUI) clear back to 8.0.
Bah, I think that is the source of the problem. Having grepped the
source for
--- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Dave Page [EMAIL PROTECTED]
Sent: 26/11/07, 22:02:09
Subject: Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
I believe that that is talking specifically about shared libraries (or
DLLs in Windows-speak),
Dave Page [EMAIL PROTECTED] writes:
Yes, I know. Peter seemed to be saying that nothing except postgres
itself should be in *any* of the installation directories
Yeah, that's what I think he said too, but it strikes me as a completely
bogus policy --- what about contrib modules or stuff from
On Nov 27, 2007 8:04 AM, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
... So
unfortunately I can't just add a TypeName member to ArrayExpr.
That would be quite the wrong thing to do anyway, since ArrayExpr is
a run-time representation and shouldn't have any such
Brendan Jurd [EMAIL PROTECTED] writes:
I'm not 100% clear on what the A_ prefix signifies ... is A_ArrayExpr
a good name for the parse-time structure?
Yeah, might as well use that for consistency. The A_ doesn't seem
very meaningful to me either, but I don't want to rename the existing
Tom Lane [EMAIL PROTECTED] writes:
AFAICS that produces runs that are *exactly* the same length as Knuth's
method --- you're just using a different technique for detecting when
the run is over, to wit record is not in heap vs record is in heap
but with a higher run number. I guess you would
Hello,
this issue has been requested and its on the TODO-list. Since I really
need foreign key constraints on inherited tables, I have two solutions:
Adding some hackish RULES/TRIGGERS to my tables or implementing it
myself. It think the latter is better. However, I have no experience in
On Mon, 2007-11-26 at 17:02 -0500, Tom Lane wrote:
I believe that that is talking specifically about shared libraries (or
DLLs in Windows-speak), and not about configuration or data files.
In particular, nothing under libdir would be a candidate to go under
sharedir, nor vice versa, since the
--- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Dave Page [EMAIL PROTECTED]
Sent: 26/11/07, 22:30:17
Subject: Re: [HACKERS] Locating sharedir in PostgreSQL on Windows
Dave Page [EMAIL PROTECTED] writes:
Yes, I know. Peter seemed to be saying that nothing except
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I guess you would save some comparisons
while the heap is shrinking, but it's not at all clear that you'd save
more than what it will cost you to re-heapify all the dead records once
the run is over.
This sounded
Mark Cave-Ayland [EMAIL PROTECTED] writes:
Okay, I'll try and expand on this a bit. In order to convert coordinates
between different coordinate systems, PostGIS uses the external PROJ.4
library. Now in order to support a certain category of conversion,
PROJ.4 requires access to a set of
On Mon, 2007-11-26 at 09:55 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
But I think there must be an action that we can take for 8.3 and that
much runtime should not be given away easily. ISTM that we can win back
the losses Guillaume has identified, plus gain a little more
Simon Riggs [EMAIL PROTECTED] writes:
Here's where I am:
Basic test was to replace call to oper_select_candidate with a single
item that was fed by a hardcoded value for varchar equality operator.
Well, that confirms what we knew from gprof, but surely you aren't
proposing that as a usable
Bruce Momjian wrote:
D'Arcy J.M. Cain wrote:
On Sat, 24 Nov 2007 11:27:38 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
I am confused about two other items with MONEY. First, why can't
anything but a string be cast to this type?
test= select 871234872319489323::money;
On Mon, 2007-11-26 at 18:18 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Here's where I am:
Basic test was to replace call to oper_select_candidate with a single
item that was fed by a hardcoded value for varchar equality operator.
Well, that confirms what we knew from
Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
But I think there must be an action that we can take for 8.3 and that
much runtime should not be given away easily. ISTM that we can win back
the losses Guillaume has identified, plus gain a little more even.
Perhaps some sanity could
Jacob Rief [EMAIL PROTECTED] writes:
this issue has been requested and its on the TODO-list. Since I really
need foreign key constraints on inherited tables, I have two solutions:
Adding some hackish RULES/TRIGGERS to my tables or implementing it
myself. It think the latter is better.
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO list:
* Allow MONEY to be cast to/from other numeric data types
So in other words, that's been added to the TODO list *purely* on your
own say-so, and not because any users asked for it or anyone else thinks
it's a good idea.
Since
Gregory Stark [EMAIL PROTECTED] writes:
I'm a bit puzzled myself why this affects SELECT FOR UPDATE/SHARE but not
straight UPDATES and DELETES.
In straight UPDATE/DELETE we have enough structure in the query to know
how to associate each tuple returned to the executor top level with
exactly one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 21:19:48 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Added to TODO list:
* Allow MONEY to be cast to/from other numeric data types
So in other words, that's been added to the
Joshua D. Drake [EMAIL PROTECTED] writes:
Well if we are going to continue to support money (which I am against)
we should support the casting to numeric as that is by far a more
common implementation of money and we will have mixed environments.
So, you don't use MONEY, and you don't want to,
Tom Lane wrote:
Since Simon seems intent on hacking something in there, here is a patch
that I think is actually sane for improving operator lookup speed.
This patch caches all lookups, exact or ambiguous (since even the exact
ones require multiple cache searches in common cases); and behaves
Bruce Momjian [EMAIL PROTECTED] writes:
We are also talking about catlog changes for 8.3. Are we comfortable
doing catalog changes between the beta and RC?
The catalog changes in question seem entirely safe ... certainly much
more so than this patch ...
I do see your point that another beta
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Well if we are going to continue to support money (which I am against)
we should support the casting to numeric as that is by far a more
common implementation of money and we will have mixed environments.
So, you don't use MONEY,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 23:47:04 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
Perhaps all we need is a way to accomplish the casting so it isn't
automatic. This works:
test= SELECT regexp_replace('2343'::money::text, '[^$,]*',
'',
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 26 Nov 2007 23:47:04 -0500 (EST)
Bruce Momjian [EMAIL PROTECTED] wrote:
Perhaps all we need is a way to accomplish the casting so it isn't
automatic. This works:
test= SELECT
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
We are also talking about catlog changes for 8.3. Are we comfortable
doing catalog changes between the beta and RC?
The catalog changes in question seem entirely safe ... certainly much
more so than this patch ...
I do see your
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
We are also talking about catlog changes for 8.3. Are we comfortable
doing catalog changes between the beta and RC?
The catalog changes in question seem entirely safe ... certainly much
more so than this patch ...
Tom Lane wrote:
Yeah, that's what I think he said too, but it strikes me as a completely
bogus policy --- what about contrib modules or stuff from pgfoundry
or any random user-written module that was built with PGXS? All that
stuff happily drops files under $libdir and $sharedir, and I see no
Tom Lane wrote:
Aside from the semantic-gap issue, there is the point that providing
a cast might actually mask application errors. I can well imagine
cases where one of the reasons for using MONEY is *exactly* that it's
not a plain number or easily convertible to one.
I'm always against
i'd like to try to develop some improvements to psqlodbc. is there
source for a test suite available? could anyone point me towards it,
or offer testing source code they've written personally?
thanks,
john
---(end of broadcast)---
TIP 2: Don't
82 matches
Mail list logo
