On Tue, 2006-03-21 at 17:47 -0500, Tom Lane wrote:
> I'm fairly unconvinced about Simon's underlying premise --- that we
> can't make good use of work_mem in sorting after the run building phase
> --- anyway.
We can make good use of memory, but there does come a point in final
merging where too
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
Is there a difference in how the executor treat a C function and a
function using a call handler that can cause this behavior?
Can't think of one. You'd better take a closer look at your call
handler.
gdb'ing with a watchpoi
On Tue, 21 Mar 2006, Tom Lane wrote:
satoshi nagayasu <[EMAIL PROTECTED]> writes:
Oleg Bartunov wrote:
I and Teodor are going to give a talk on conference "Corporate database
systems-2006" here in Moscow and we need info about new features planned
in 8.2 release. Bruce, do you have a list of t
unsubscribe
---(end of broadcast)---
TIP 6: explain analyze is your friend
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> ... The real issue is what types and type mechanisms should be in the
> postgresql core distribution. We won't win any thanks from anyone if we
> reduce them. Getting some types right is hard. There is no case that I can
> see for pushing timestamps, n
remove my email from the list
Regards,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Andrew Dunstan
Sent: Wednesday, March 22, 2006 9:05 AM
To: [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Modular Type Libraries: was A real
Trent Shipley <[EMAIL PROTECTED]> writes:
> Without directly addressing the merits of enumerations, enumeration
> interfaces, real currency and time zone types, or whether currency and time
> zone types should be built using enumerations, I would like to ask the
> powers-that-be to seriously con
Trent Shipley said:
> Without directly addressing the merits of enumerations, enumeration
> interfaces, real currency and time zone types, or whether currency and
> time zone types should be built using enumerations, I would like to
> ask the powers-that-be to seriously consider radically modular
Without directly addressing the merits of enumerations, enumeration
interfaces, real currency and time zone types, or whether currency and time
zone types should be built using enumerations, I would like to ask the
powers-that-be to seriously consider radically modularizing Postgresql's type
sy
Tom Lane said:
> I was thinking something more like a CREATE ENUM TYPE command that
> specifically lists the enum values, and some extension of that to cater
> for tagged types, and the values are put into a system catalog that the
> user doesn't manipulate directly. I don't see why it's a good id
On 3/21/06, satoshi nagayasu <[EMAIL PROTECTED]> wrote:
However, we also need to know why business people wantto know about the future plan. For the business people,the roadmap is used to know the software is fit totheir (growing) business, not only now but in the future.
With the current timeline
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Is there a difference in how the executor treat a C function and a
> function using a call handler that can cause this behavior?
Can't think of one. You'd better take a closer look at your call
handler.
gdb'ing with a watchpoint on writes to Current
Tom Lane wrote:
> In particular, asking for a list of features that will be done in
> particular future releases shows a complete lack of understanding
> of the process ...
I completely understand.
However, we also need to know why business people want
to know about the future plan. For the busin
satoshi nagayasu <[EMAIL PROTECTED]> writes:
> Oleg Bartunov wrote:
>> I and Teodor are going to give a talk on conference "Corporate database
>> systems-2006" here in Moscow and we need info about new features planned
>> in 8.2 release. Bruce, do you have a list of them ?
> Refer to the Josh's
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
As it turns out, I'm not supposed to allocate the returned tuple in the
caller context.
Where do you get that from? plpgsql and plperl both do it that way AFAICS.
Are you testing in an --enable-cassert build? The memory-clo
Martijn van Oosterhout writes:
> On Tue, Mar 21, 2006 at 05:55:09PM -0500, Tom Lane wrote:
>> Yes, you can
>> think of advanced applications where it's useful to have random
>> additional stuff in the table, but that's exactly the point at which you
>> normally have to get down-and-dirty with some
Oleg,
Refer to the Josh's past talk, "PostgreSQL Directions 8.1 and beyond".
MP3 and materials of are available:
http://www.postgresql.jp/misc/seminar/2006-02-17_18/materials/01_Josh_Berkus.pdf
http://www.postgresql.jp/misc/seminar/2006-02-17_18/materials/01_Josh_Berkus.mp3
Thanks,
Satoshi Nagay
On Tue, Mar 21, 2006 at 05:55:09PM -0500, Tom Lane wrote:
> Yes, you can
> think of advanced applications where it's useful to have random
> additional stuff in the table, but that's exactly the point at which you
> normally have to get down-and-dirty with some C code --- after all, what
> is st
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> Experiment should take but a minute to validate or disprove the hypothesis.
Only if you're prepared to trust the results of one experiment on one
platform with a not-very-large amount of data. Otherwise it's going to
take quite a few minutes ...
The
Tom,
On 3/21/06 2:47 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> I'm fairly unconvinced about Simon's underlying premise --- that we
> can't make good use of work_mem in sorting after the run building phase
> --- anyway. If we cut back our memory usage then we'll be forcing a
> significantly mor
Martijn van Oosterhout writes:
> Let me put it this way: if this is to progress beyond just a contrib
> module, it needs to go all the way (special syntax, pg_dump, etc). I'm
> not sure if I'm that enamoured with it to want all that.
My feelings in a nutshell ;-)
> The only way to avoid that is
Martijn van Oosterhout writes:
> There is one way to guarentee the memory is released to the OS after
> completion. Make the allocator allocate work_mem bytes using mmap()
> rather than malloc(). munmap() will then definitly return the memory to
> the OS. Unfortunatly, the coding required would pr
On Tue, Mar 21, 2006 at 05:25:15PM -0500, Tom Lane wrote:
> The dump should look the same as the commands originally used to create
> the type, which is surely not going to happen with that "SELECT
> create_tagged_type()" stuff barring pg_dump modifications. Otherwise
> we are nailing down not one
On Tue, Mar 21, 2006 at 08:05:50PM +, Simon Riggs wrote:
> > Point 2 is actually a serious flaw in Simon's proposal, because there
> > is no portable way to make malloc return freed memory to the OS. Some
> > mallocs will do that ... in some cases ... but many simply don't ever
> > move the br
Martijn van Oosterhout writes:
> Really? The code creates ordinary types, operators and functions, all
> of which are dumped fine by pg_dump. Dependancies are created which
> should ensure the parts get dumped in the right order. What special
> support in pg_dump were you envisioning?
The dump sh
On Tue, Mar 21, 2006 at 03:59:31PM -0500, Andrew Dunstan wrote:
> >I think such types would be better implemented as some sort of
> >structured type, possibly with constructors and methods and all the
> >other stuff that SQL talks about. We don't have all of that yet --
> >maybe we don't need a
On Sat, 2006-03-18 at 13:21 -0800, Luke Lonergan wrote:
> In short, faster performance through more aggressive runtime compilation. A
> JIT for the database kernel. It's not like I'm on shaky ground here - other
> commercial DBMS have done it for over a decade.
I think what Luke may be referrin
On Tue, Mar 21, 2006 at 04:10:21PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > I'd like it to be considered for inclusion.
>
> The description page lists sufficiently many unresolved issues that
> I'd have to call it "not ready for prime time" ... even assuming there
> are not any
Greg Stark <[EMAIL PROTECTED]> writes:
> My question explicitly recognized that possibility. I'm just a little
> skeptical since the comparison function in Postgres is often not some simple
> bit of tightly optimized C code, but rather a complex locale sensitive
> comparison function or even a bit
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > That looks better both on average and in the worst case. Are the time
> > constants that much worse that the merge sort still takes longer?
>
> Keep in mind that this is only counting the number of
> comparison-func
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> As it turns out, I'm not supposed to allocate the returned tuple in the
> caller context.
Where do you get that from? plpgsql and plperl both do it that way AFAICS.
Are you testing in an --enable-cassert build? The memory-clobber
behavior that that
Martijn van Oosterhout writes:
> I'd like it to be considered for inclusion.
The description page lists sufficiently many unresolved issues that
I'd have to call it "not ready for prime time" ... even assuming there
are not any issues you failed to identify. One showstopper I can cite
immediatel
Peter Eisentraut wrote:
Bruce Momjian wrote:
This looks very interesting. Should we add it to the core
distribution?
I think such types would be better implemented as some sort of
structured type, possibly with constructors and methods and all the
other stuff that SQL talks about.
Greg Stark <[EMAIL PROTECTED]> writes:
> That looks better both on average and in the worst case. Are the time
> constants that much worse that the merge sort still takes longer?
Keep in mind that this is only counting the number of
comparison-function calls; it's not accounting for any other effe
Bruce Momjian wrote:
> This looks very interesting. Should we add it to the core
> distribution?
I think such types would be better implemented as some sort of
structured type, possibly with constructors and methods and all the
other stuff that SQL talks about. We don't have all of that yet --
Tom Lane <[EMAIL PROTECTED]> writes:
> and here are the results using glibc's qsort, which of course isn't
> quicksort at all but some kind of merge sort:
> ...
> Overall: average cratio 0.63 over 525 tests
That looks better both on average and in the worst case. Are the time
constants that much
Last month I wrote:
> It seems clear that our qsort.c is doing a pretty awful job of picking
> qsort pivots, while glibc is mostly managing not to make that mistake.
I re-ran Gary's test script using the just-committed improvements to
qsort.c, and got pretty nice numbers (attached --- compare to
h
On Fri, 2006-03-17 at 09:46 -0500, Tom Lane wrote:
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> > So what's the difference between these two strategy?
> > (1) Running time: do they use the same amount of memory? Why option 2 is
> > better than 1?
> > (2) Idle time: after sort done, option 1 will
On Tue, Mar 21, 2006 at 02:00:14PM -0500, Gregory Maxwell wrote:
> On 3/21/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> > ISTM that having a currency type is pretty common for most databases; I
> > don't really see any reason not to just include it. Likewise for a type
> > that actually stores tim
On 3/21/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> ISTM that having a currency type is pretty common for most databases; I
> don't really see any reason not to just include it. Likewise for a type
> that actually stores timezone info with a timestamp.
This really should be generalized to work w
David,
Thanks for the tip. A diff on the plperl source was really helpful.
As it turns out, I'm not supposed to allocate the returned tuple in the
caller context. Apparently, PostgreSQL will always make a copy of it. I
find this a bit inconsistent with how other return values are handled.
PL/J
"Dann Corbit" <[EMAIL PROTECTED]> writes:
> Well, my point was that it is a snap to implement and test.
Well, having done this, I have to eat my words: it does seem to be a
pretty good idea.
The following test numbers are using Bentley & McIlroy's test framework,
but modified to test only the cas
On Tue, Mar 21, 2006 at 09:39:09AM -0800, Josh Berkus wrote:
> Bruce, Martijin,
>
> > > This looks very interesting. Should we add it to the core distribution?
> >
> > Excellent question. As yet I have received very little feedback on it,
> > though it does work as advertised. I have had some peo
On Tue, Mar 21, 2006 at 06:15:29PM +0100, Pailloncy Jean-Gerard wrote:
> >>This looks very interesting. Should we add it to the core
> >>distribution?
> >
> >Excellent question. As yet I have received very little feedback on it,
> >though it does work as advertised. I have had some people compla
Bruce, Martijin,
> > This looks very interesting. Should we add it to the core distribution?
>
> Excellent question. As yet I have received very little feedback on it,
> though it does work as advertised. I have had some people complain that
> while they'd like to use it (especially the timestamp
This looks very interesting. Should we add it to the core
distribution?
Excellent question. As yet I have received very little feedback on it,
though it does work as advertised. I have had some people complain
that
while they'd like to use it (especially the timestamp-that-remembers-
the-ti
Magnus Jonsson <[EMAIL PROTECTED]> writes:
> I discoverd what seems to be a bug in postgresql 7.4.12 (also on
> 7.4.7).
AFAIR, 7.4 and earlier didn't really have a sane way of representing
NULL composite-type values, so this aggregate isn't going to work
before 8.0.
regar
On Tue, Mar 21, 2006 at 09:59:40AM -0500, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > At the time it sets max_connections there is no server to test against.
> > initdb in fact never uses a standard client connection at all, and never
> > starts postmaster. To do a check on m
Hello,
I discoverd what seems to be a bug in postgresql 7.4.12 (also on
7.4.7).
I have an example located at http://foo.fot.nu/psql/ with a simple
example that delevers the correct result on 8.1 (tested by some nice
person at #postgresql).
It seems like the state variable is reseted every time
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> At the time it sets max_connections there is no server to test against.
> initdb in fact never uses a standard client connection at all, and never
> starts postmaster. To do a check on max_connections you would have to
> start postmaster and then try
On Tue, Mar 21, 2006 at 08:49:18AM -0500, Bruce Momjian wrote:
>
> This looks very interesting. Should we add it to the core distribution?
Excellent question. As yet I have received very little feedback on it,
though it does work as advertised. I have had some people complain that
while they'd l
delete my email from the list
Regards,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Magnus Jonsson
Sent: Tuesday, March 21, 2006 8:39 PM
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] Problems with CREATE AGGREGATE and user defined state
type.
Pavel Stehule wrote:
> Hello,
>
> This patch is well, I hope. I didn't look on it half year. Contains: SQL/XML
> support + doc by D.Fetter
> http://candle.pha.pa.us/mhonarc/patches_hold/msg00134.html
Yes, I am just looking at it now.
--
Bruce Momjian http://candle.pha.pa.us
SRA OSS, Inc.
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Ok, lets go back to my original point then: initdb should be made to
> check that you can actually open as many connections as it's trying to
> set max_connections to.
Apparently you are unaware that it's done that for a long time.
Jim C. Nasby wrote:
Adding -hackers.
[removing -buildfarm :-) ]
Ok, lets go back to my original point then: initdb should be made to
check that you can actually open as many connections as it's trying to
set max_connections to. If it can't, it should drop max_connections down
(and possibly
Adding -hackers.
On Tue, Mar 21, 2006 at 02:20:09PM +0100, Christian Mair wrote:
>
> > No, let's start again.
> >
> > The user's machine ran out of resources. That can't be because inbitdb set
> > max_connections too low - if anything it has probably set them too high. I
> > suggested that he co
Oleg Bartunov said:
> Hi there,
>
> I and Teodor are going to give a talk on conference
> "Corporate database systems-2006" here in Moscow and we need info about
> new features planned in 8.2 release. Bruce, do you have a list of them
> ?
>
>
Speaking of which, I previously said that I intended t
This looks very interesting. Should we add it to the core distribution?
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> For a while I've been wondering about making a type that was really a
> shell aroun
Hi there,
I and Teodor are going to give a talk on conference
"Corporate database systems-2006" here in Moscow and we need info about new
features planned in 8.2 release. Bruce, do you have a list of them ?
Regards,
Oleg
___
I have attached pgrowlocks tested under current.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Tatsuo, have you developed a new version of this for 8.2?
>
> ---
>
> Tatsuo Ishii wrote:
> > > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
60 matches
Mail list logo
