Tom Lane <[EMAIL PROTECTED]> writes:
> There is some stuff in the literature about how to make transformations
> of the last kind, but it requires additional executor smarts to do strange
> sorts of "generalized outer join" operations.
Would these "generalized outer join" operations be general
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> There is some stuff in the literature about how to make transformations
>> of the last kind, but it requires additional executor smarts to do strange
>> sorts of "generalized outer join" operations.
> Would these "g
On Thu, Dec 15, 2005 at 12:04:33AM +0100, Zoltan Boszormenyi wrote:
> The VIEW is created like this (shorter example):
>
> create view v1 (code,num) as
> select 'AAA',id from table1
> union
> select 'BBB',id from table2;
>
> I created the indexes on the individual tables as
>
> create index inde
On Thu, Dec 15, 2005 at 09:25:42AM -0500, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> There is some stuff in the literature about how to make transformations
> >> of the last kind, but it requires additional executor smarts to do strange
>
On Thu, Dec 15, 2005 at 12:50:44AM -0500, Tom Lane wrote:
> Mark Kirkwood <[EMAIL PROTECTED]> writes:
> > I don't know if this is yet another one, but happened to rebuild 7.3.12
> > on a FreeBSD 6.0 box today and I notice that it fails float8 regression
> > test (geometry does too but that is mar
On Thu, Dec 15, 2005 at 12:10:37AM -0500, Qingqing Zhou wrote:
>
> On Wed, 14 Dec 2005, Luke Lonergan wrote:
> >
> > Overall - I'd say that the BSD routine is showing the best overall results
> > when the scale test is included. The qsortG routine has some significantly
> > better performance in
On Tue, Dec 13, 2005 at 04:49:10PM -0500, Neil Conway wrote:
> On Tue, 2005-12-13 at 22:32 +0100, Joachim Wieland wrote:
> > there's a topic that comes up from time to time on the lists, the problem
> > that pgsql functions get planned only once and thereafter the same query
> > plan is used until
On Thu, 15 Dec 2005, Jim C. Nasby wrote:
>
> I have access to both some (SLOW) ultra5's and a machine running
> opensolaris on AMD if testing there would help. I'll need a pointer to a
> patch and test-case though...
>
Thanks! I've patched the program with the following changes:
(1) add gcc-min
On Thursday 15 December 2005 12:02, Jim C. Nasby wrote:
> On Thu, Dec 15, 2005 at 12:50:44AM -0500, Tom Lane wrote:
> > Mark Kirkwood <[EMAIL PROTECTED]> writes:
> > > I don't know if this is yet another one, but happened to rebuild 7.3.12
> > > on a FreeBSD 6.0 box today and I notice that it fails
Robert Treat wrote:
The one thing I am wondering is would people accept older OS's into the
buildfarm? I think there are still a lot of servers running red hat 7.3,
that might be an example of an old OS that we could put into the buildfarm to
test for the 7.3.x or 7.4.x series.
"peop
Robert Treat <[EMAIL PROTECTED]> writes:
> The one thing I am wondering is would people accept older OS's into the
> buildfarm? I think there are still a lot of servers running red hat 7.3,
> that might be an example of an old OS that we could put into the buildfarm to
> test for the 7.3.x or 7.
On Thu, Dec 15, 2005 at 01:16:09PM -0500, Robert Treat wrote:
> > Well, you could make the argument that switching OSes is a lot less
> > involved than switching PostgreSQL versions, especially since a
> > dump/reload isn't required...
> >
>
> How exactly do you switch the OS your database is runn
Hi all,
Quite new to Postgres and initially driven here due to PostGIS. One
thing I was looking at was the ability to roll back to a certain time,
multiple editing, and QC. Basically a version control for databases. I
went through the TODO list and I don't see this listed there, unless it
is
PITR will allow you to recover a database to a specific point in time,
if that's what you're looking for. Otherwise you're probably stuck
rolling your own, but fortunately rules make that pretty easy to do.
On Thu, Dec 15, 2005 at 04:05:33PM -0600, Amit Kulkarni wrote:
> Hi all,
>
> Quite new to
Jim C. Nasby írta:
Those queries aren't the same though. The view is equivalent to
SELECT *
FROM
(select 'AAA' AS prefix,id from table 1
union select 'AAA',id from table 2
) view
WHERE prefix||id = '...'
In this case the prefixes have already been unioned together, so there's
no c
> > > Based on this it seems like we should expose the option to choose the BSD
> > > qsort routine at configure time.
I have a related question. qsort is only used in the postgres source in a few
places. If postgres used an internal implementation instead of the library
source it could have impl
Greg Stark <[EMAIL PROTECTED]> writes:
> I have a related question. qsort is only used in the postgres source in a few
> places. If postgres used an internal implementation instead of the library
> source it could have implementations that don't use function pointers.
There are calls to qsort in u
On Thu, 15 Dec 2005, Greg Stark wrote:
>
> I have a related question. qsort is only used in the postgres source in a few
> places. If postgres used an internal implementation instead of the library
> source it could have implementations that don't use function pointers. This
> might perform fast
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Qingqing Zhou
> Sent: Thursday, December 15, 2005 3:16 PM
> To: Greg Stark
> Cc: Jim C. Nasby; Luke Lonergan; Tom Lane; Neil Conway; Bruce Momjian;
> pgsql-hackers@postgresql.org
> Subject
I'm not sure whether we'd need any additional planner knobs to control
this. I think that the existing join_collapse_limit GUC variable should
continue to exist, but its effect on left/right joins will be the same as
for inner joins. If anyone wants to force join order for outer joins more
than
I'm not sure whether we'd need any additional planner knobs to control
this. I think that the existing join_collapse_limit GUC variable should
continue to exist, but its effect on left/right joins will be the same as
for inner joins. If anyone wants to force join order for outer joins more
than
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> Radix sort can also be made completely generic by using a callback
> function.
> The function gives back n-bits at a time, from the most significant bits
> to the least significant.
That's mighty handwavy --- it assumes that the datatype permits a simple
[Face flushed begin]
Thanks for Greg "let" me take a second look at qsortB.c - there is
paste-and-copy error there, so when it perform recursive sort, it calls
glibc's qsort ... Really sorry, and feel a little bit gun-shy now ...
[Face flushed continue]
After I re-tested it, now BSD qsort is
Qingqing,
On 12/15/05 6:33 PM, "Qingqing Zhou" <[EMAIL PROTECTED]> wrote:
> Thanks for Greg "let" me take a second look at qsortB.c - there is
> paste-and-copy error there, so when it perform recursive sort, it calls
> glibc's qsort ... Really sorry, and feel a little bit gun-shy now ...
>
> Afte
On Fri, 16 Dec 2005, Luke Lonergan wrote:
>
> Can you post the new results like the last post?
>
Yeah, it is at the same website (I disabled Jim's result since he hasn't
updated using the new program).
Regards,
Qingqing
---(end of broadcast)---
25 matches
Mail list logo
