Tom Lane wrote:
"Atul Deopujari" <[EMAIL PROTECTED]> writes:
Yes, letting the planner make its own decision would seem best (in
accordance with what we do for different join paths). But for large IN
lists, a substantial part of the planner is spent in estimating the
selectivity of the Scalar
On Thu, 17 May 2007, David Fetter wrote:
Would you be interested in providing this meat? You're uniquely
qualified because your shins still smart from all the things you
barked them on :)
Unfortunately I'm temporarily on the other side of this problem; all the
time I have to spare right now
"Andrew Hammond" <[EMAIL PROTECTED]> writes:
> On 5/17/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> What are the grounds for defining it that way rather than some other
>> way?
> The only alternative that came to mind when I wrote it was using a numeric
> instead of float.
No, I'm wondering what's
On 5/17/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Andrew Hammond <[EMAIL PROTECTED]> writes:
> Yet another potential addition to the family of operators. Some guy
> was asking for it on IRC so...
> CREATE OR REPLACE FUNCTION interval_over_interval(interval, interval)
> RETURNS float STRICT IMMUTA
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are we going to apply this?
Not in the form submitted so far, but I trust Magnus is working on
fixing it.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your
Andrew Hammond <[EMAIL PROTECTED]> writes:
> Yet another potential addition to the family of operators. Some guy
> was asking for it on IRC so...
> CREATE OR REPLACE FUNCTION interval_over_interval(interval, interval)
> RETURNS float STRICT IMMUTABLE LANGUAGE sql AS $$
> SELECT extract(epoch from
Are we going to apply this? I would also like to see a comment added on
why we use SO_REUSEADDR.
---
Magnus Hagander wrote:
> On Mon, May 14, 2007 at 09:34:05AM -0400, Andrew Dunstan wrote:
> >
> >
> > Magnus Hagander wro
Yet another potential addition to the family of operators. Some guy
was asking for it on IRC so...
CREATE OR REPLACE FUNCTION interval_over_interval(interval, interval)
RETURNS float STRICT IMMUTABLE LANGUAGE sql AS $$
SELECT extract(epoch from $1)::float / extract(epoch from $2);
$$;
CREATE OPER
Added to TODO:
---
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > Is there a TODO here?
>
> Yes, I think so:
>
> * Implement the SQL standard mechanism whereby REVOKE ROLE only revokes
> the privilege as granted b
I have updated the patch status page:
http://developer.postgresql.org/index.php/Todo:PatchStatus#current_8.3_patch_status
I moved some patches that were clearly not ready to the 8.4 queue.
Let's see what we can get applied in the next week and review our
status then.
--
Bruce Momjian <[E
Bruce Momjian wrote:
>
> Is there a TODO here?
Yes, I think so:
* Implement the SQL standard mechanism whereby REVOKE ROLE only revokes
the privilege as granted by the invoking role, and not those granted
by other roles
--
Alvaro Herrerahttp://www.CommandPr
Is there a TODO here?
---
Russell Smith wrote:
> Alvaro Herrera wrote:
> > Russell Smith wrote:
> >
> >> Alvaro Herrera wrote:
> >>
> >>> Alvaro Herrera wrote:
> >>>
> >>>
> >>>
> 2. decide that the sta
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is there still a TODO here?
> Tom Lane wrote:
>> Fix parameter recalculation for Limit nodes:
No, it's fixed AFAIK. Till someone finds another bug anyway ;-)
regards, tom lane
---(end of broadcast)-
On Thu, May 17, 2007 at 10:14:45PM +0200, Magnus Hagander wrote:
> IIRC, Joachim had started working on the ecpg part. (Which is one of the
> reasons I haven't looked at it myself yet)
> Joachim, did you ever get anywhere with that?
I have ecpg tests somehow running under msvc but there are still
Is there still a TODO here?
---
Tom Lane wrote:
> Log Message:
> ---
> Fix parameter recalculation for Limit nodes: during a ReScan call we must
> recompute the limit/offset immediately, so that the updated values ar
OK, date remains unchanged.
---
Marc G. Fournier wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> - --On Thursday, May 17, 2007 09:20:30 -0700 "Joshua D. Drake"
> <[EMAIL PROTECTED]> wrote:
>
>
> > I sa
"Atul Deopujari" <[EMAIL PROTECTED]> writes:
> Yes, letting the planner make its own decision would seem best (in
> accordance with what we do for different join paths). But for large IN
> lists, a substantial part of the planner is spent in estimating the
> selectivity of the ScalarArrayExpr by
Andrew Dunstan wrote:
>
> We've had ecpg regression tests being doing by the buildfarm for a
> while, but they are not enabled for MSVC. Also, buildfarm has never
> supported doing MBCS regression tests. In both cases the regression
> tests are driven by Unix shell scripts, and in the MBCS case at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, May 17, 2007 09:20:30 -0700 "Joshua D. Drake"
<[EMAIL PROTECTED]> wrote:
> I say we wait until we actually know where we are at. How is that comparative
> from Tom's triage to my email coming?
I agree ... a date gives ppl somethi
Hello,
It seems that it may be useful to allow something like:
DROP INDEX NOWAIT.
The idea being, that the terminal will come back, the index will be
dropped in the background. If it doesn't drop, it rollback like normal
and logs.
I bring this up now, as an idea. We can argue about it later
Hi,
Tom Lane wrote:
"Atul Deopujari" <[EMAIL PROTECTED]> writes:
Hi,
Tom Lane wrote:
That's the least of the problems. We really ought to convert such cases
into an IN (VALUES(...)) type of query, since often repeated indexscans
aren't the best implementation.
I thought of giving this a shot
Heikki Linnakangas wrote:
There are few things that we can separate easily, like CREATE INDEX
related changes, VACUUM and VACUUM FULL related changed, space
reuse related changes etc. Let me give it a shot.
Did we ever get a broken up patch for this?
Yes:
http://archives.postgresql.org/pgsq
Andrew Dunstan wrote:
That's a good point. So, do we want/need the same for MBCS and ECPG tests?
It would be nice for ECPG. I wasn't even aware of the MBCS stuff - if it
will exercise the unicode sorting which is a little different on Windows
iirc (due to the lack of full native UTF-8 supp
Joshua D. Drake wrote:
Pavan Deolasee wrote:
I suppose inserting HOT tuples without index maintenance is useful
even if no
changes to the space allocation is made is useful. It won't get the
space
usage but it would save on index thrashing. But that still implies
all the
On 5/17/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
Pavan Deolasee wrote:
>
>
> There are few things that we can separate easily, like CREATE INDEX
> related changes, VACUUM and VACUUM FULL related changed, space
> reuse related changes etc. Let me give it a shot.
Did we ever get a broken u
Joshua D. Drake wrote:
> Tom Lane wrote:
>
> > At this point it seems nothing will be done about this issue for 8.3.
> >
> > * [PATCHES] plpgpsm /Pavel Stehule/
> >
> > I think this has to be held for 8.4: it was submitted too late for the 8.3
> > feature deadline, and in fact I don't recall th
Pavan Deolasee wrote:
I suppose inserting HOT tuples without index maintenance is useful
even if no
changes to the space allocation is made is useful. It won't get the
space
usage but it would save on index thrashing. But that still implies
all the
code to handle sca
This is not ready for 8.3.
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Heikki Linnakangas wrote:
> It's been known for years that commit_delay isn't very good a
Tom Lane wrote:
At this point it seems nothing will be done about this issue for 8.3.
* [PATCHES] plpgpsm /Pavel Stehule/
I think this has to be held for 8.4: it was submitted too late for the 8.3
feature deadline, and in fact I don't recall that there was any community
discussion/consensus o
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I don't think ECPG can use pg_regress as is, because it does more than
> just run psql. We probably need to look at factoring out the common bits
> into a shared lib. That's not a bad idea anyway.
A shared library is probably overkill (it has a lot mo
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Back when we were thinking of supporting MSVC builds, we thought that
everything would need to be a C program, and so we rewrote the main
regression script in C, for example. However, now we have a build system
for MSVC we can see
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Back when we were thinking of supporting MSVC builds, we thought that
> everything would need to be a C program, and so we rewrote the main
> regression script in C, for example. However, now we have a build system
> for MSVC we can see that its main
Thank you for your suggestions, I am thinking about "Full page writes
improvement". It seems not so complicated, just fit for a novice like
me.
I'll work on it. :-)
2007/5/17, Heikki Linnakangas <[EMAIL PROTECTED]>:
Cui Shijun wrote:
> I see...
> I checked part of HOT patches(patch1), and fou
Bruce Momjian wrote:
Right now our roadmap lists the 8.3 release as July, 2007:
http://www.postgresql.org/developer/roadmap
While the year might be right, the month probably is not. I suggest we
remove the date and replace it with "undetermined" until we have a
clearer target date.
I
Andrew Sullivan wrote:
> On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
>
> > This is what happens with the Linux kernel. They have hundreds of
> > developers getting their hands dirty during a previous period. Then
> > 2.6.20 is released; the 2.6.21 "merge window" opens, and al
Right now our roadmap lists the 8.3 release as July, 2007:
http://www.postgresql.org/developer/roadmap
While the year might be right, the month probably is not. I suggest we
remove the date and replace it with "undetermined" until we have a
clearer target date.
--
Bruce Momjian <[EM
Dave Page wrote:
Andrew Dunstan wrote:
We've had ecpg regression tests being doing by the buildfarm for a
while, but they are not enabled for MSVC. Also, buildfarm has never
supported doing MBCS regression tests. In both cases the regression
tests are driven by Unix shell scripts, and in th
OK, emails moved to 8.4 queue.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Your patch has been added to the PostgreSQL unapplied patches list at:
>
> Please take it off again.
>
> > Jeff Davis wrote
Andrew Dunstan wrote:
>
> We've had ecpg regression tests being doing by the buildfarm for a
> while, but they are not enabled for MSVC. Also, buildfarm has never
> supported doing MBCS regression tests. In both cases the regression
> tests are driven by Unix shell scripts, and in the MBCS case at
Joshua D. Drake wrote:
Andrew Sullivan wrote:
On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
This is what happens with the Linux kernel. They have hundreds of
developers getting their hands dirty during a previous period. Then
2.6.20 is released; the 2.6.21 "merge window"
We've had ecpg regression tests being doing by the buildfarm for a
while, but they are not enabled for MSVC. Also, buildfarm has never
supported doing MBCS regression tests. In both cases the regression
tests are driven by Unix shell scripts, and in the MBCS case at least,
the script would ne
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Your patch has been added to the PostgreSQL unapplied patches list at:
Please take it off again.
> Jeff Davis wrote:
>> This thread here became a TODO item:
>> http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php
>>
>> During that discussi
Andrew Sullivan wrote:
On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
This is what happens with the Linux kernel. They have hundreds of
developers getting their hands dirty during a previous period. Then
2.6.20 is released; the 2.6.21 "merge window" opens, and all sort of
pat
Bruce Momjian wrote:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers reviews
> and approves it.
Wait a minute. Would the mentioned patch be th
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Je
On Tue, May 15, 2007 at 04:52:16PM -0400, Alvaro Herrera wrote:
> This is what happens with the Linux kernel. They have hundreds of
> developers getting their hands dirty during a previous period. Then
> 2.6.20 is released; the 2.6.21 "merge window" opens, and all sort of
> patches are flooded i
Cui Shijun wrote:
I see...
I checked part of HOT patches(patch1), and found that it involves too
many things I am not currently familar with. Maybe I should change an
item to work. :-(
Yeah, that's one big patch..
Since I only studied part of source codes about transaction
processing(lmgr/MVC
Hi Jeff,
On 5/16/07 4:56 PM, "Jeff Davis" <[EMAIL PROTECTED]> wrote:
>> The main benefit of a sync scan will be the ability to start the scan where
>> other scans have already filled the I/O cache with useful blocks. This will
>> require some knowledge of the size of the I/O cache by the syncsca
Greg Smith wrote:
On Thu, 17 May 2007, Andrew Dunstan wrote:
For this item at least the work has been done in showing how to set
up a local mirror using rsync instead of CVSup...although frankly it
would be better to import the information rather than just refer to
the buildfarm HOWTO.
Th
I see...
I checked part of HOT patches(patch1), and found that it involves too
many things I am not currently familar with. Maybe I should change an
item to work. :-(
Since I only studied part of source codes about transaction
processing(lmgr/MVCC/xact but without xlog.c), I want to study
"Group
On Thu, 17 May 2007, Robert Treat wrote:
And really should probably be written up into FAQ section or a full on guide
for "how do i get started hacking on postgresql?"
To be clear here: while there are guides for new hackers out there, they
focus on the big picture. I walked from those with
Pavan Deolasee wrote:
> On 5/17/07, Cui Shijun <[EMAIL PROTECTED]> wrote:
> >
> > I want to help the reviewing work of "ctid chain following enhancement ".
> > I've been studying the souce code which related with that part recently.
> > :-)
>
>
>
> Tom had objected to this patch on the grounds t
On Thu, 17 May 2007, Andrew Dunstan wrote:
For this item at least the work has been done in showing how to set up a
local mirror using rsync instead of CVSup...although frankly it would be
better to import the information rather than just refer to the buildfarm
HOWTO.
The information in the
"Atul Deopujari" <[EMAIL PROTECTED]> writes:
> Hi,
> Tom Lane wrote:
>> That's the least of the problems. We really ought to convert such cases
>> into an IN (VALUES(...)) type of query, since often repeated indexscans
>> aren't the best implementation.
>>
> I thought of giving this a shot and wh
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > This has been saved for the 8.4 release:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
> Huh, no, this is a bug and should be fixed right away.
OK, moved to the 8.3 patch queue.
--
On Thursday 17 May 2007 08:16, Andrew Dunstan wrote:
> David Fetter wrote:
> >> My main difficulty was figuring out a workable way to build a local
> >> mirror of the code (so I could get off-line diffs), keep it in sync with
> >> the development tree, while branching out working areas to evaluate
On Wednesday 16 May 2007 13:02, Robert Haas wrote:
> > I care. I want a professional easy to understand and easy to maintain
> > that doesn't cause potential conflict with future and past development
> >
> > syntax.
>
>
> If people have strong opinions about the syntax, why
> were they not ALL ex
David Fetter wrote:
My main difficulty was figuring out a workable way to build a local mirror
of the code (so I could get off-line diffs), keep it in sync with the
development tree, while branching out working areas to evaluate patches or
do new development in. A good example walkthrough
On 5/17/07, Cui Shijun <[EMAIL PROTECTED]> wrote:
I want to help the reviewing work of "ctid chain following enhancement ".
I've been studying the souce code which related with that part recently.
:-)
Tom had objected to this patch on the grounds that it adds complexity
without any significa
Hi,
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
When planning queries with a large IN expression in the WHERE clause,
the planner transforms the IN list into a scalar array expression. In
clause_selectivity(), we estimate the selectivity of the ScalarArrayExpr
by calling scalararray
Hi,
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
When planning queries with a large IN expression in the WHERE clause,
the planner transforms the IN list into a scalar array expression. In
clause_selectivity(), we estimate the selectivity of the ScalarArrayExpr
by calling scalararray
Cui Shijun wrote:
> I want to help the reviewing work of "ctid chain following enhancement ".
> I've been studying the souce code which related with that part recently.
> :-)
Please go ahead :-)
Regards Dave
---(end of broadcast)---
TIP 3: Have you
I want to help the reviewing work of "ctid chain following enhancement ".
I've been studying the souce code which related with that part recently.
:-)
2007/5/17, Dave Page <[EMAIL PROTECTED]>:
I think we just have to accept that we're gonna have a long feature
freeze period, and ask people to he
Magnus Hagander wrote:
> Right. Grabbing the msgid alone from them shouldn't be too hard though.
> It's included in the "meta-headers" mhonarc sticks in each file, so it
> should be a simple regex to find it.
Should be easier than that - when we import the existing messages from
the mbox files we
On Wed, May 16, 2007 at 11:50:26PM -0400, Greg Smith wrote:
> On Tue, 15 May 2007, Jim C. Nasby wrote:
>
> >Speaking of reviewers... should we put some thought into how we can
> >increase the number of people who can review code? It seems that's one
> >of our biggest bottlenecks...
>
> Having rec
Marc G. Fournier wrote:
>
>
> --On Wednesday, May 16, 2007 20:09:44 -0400 Bruce Momjian <[EMAIL PROTECTED]>
> wrote:
>
>> I think one of the things that is preventing urgency is that everyone
>> knows we have large patches unapplied, so they know that their lack of
>> activity is not holding up
Jim C. Nasby wrote:
> On Wed, May 16, 2007 at 07:48:10PM +0200, Magnus Hagander wrote:
>> Dave Page wrote:
> I the current URLs represent the month, and the ID of the message as
> it comes out of the mbox I believe. We could probably write a script
> to dump a list of message IDs, direc
67 matches
Mail list logo
