On Thu, Oct 13, 2005 at 08:59:51AM +, Andreas Pflug wrote:
> David Fetter wrote:
>
> >>Dept of second thoughts: actually, perhaps see if you can generate
> >>the pg_description entries from the C comments in the
> >>include/catalog header files. There's already a strong motivation
> >>to hold
On Fri, 2005-10-14 at 09:57 -0700, karen hill wrote:
> Autovacuum is getting put into the 8.1 release which
> is awesome. A lot of us are wondering now that
> PostgreSQL has all the features that many of us need,
> what are the features being planned for future
> releases?
You know, as PostgreSQL
Autovacuum is getting put into the 8.1 release which
is awesome. A lot of us are wondering now that
PostgreSQL has all the features that many of us need,
what are the features being planned for future
releases?
What do you see for 8.2 and beyond? What type of
features are you devs planning for 9.
Martijn van Oosterhout writes:
> Interestingly, I notice the windows port of PostgreSQL uses the
> QueryPerformanceCounter() function. I tried playing with it under linux
> and found that Linux suspends the CPU while waiting for things to
> happen. So:
> sleep(1)~ 20 million cycle
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Why? They certainly wouldn't be any slower than they are now.
> Well currently they get rewritten to use OR which does a single index scan
Not in 8.1 it doesn't; that code is long gone.
2005-04-24 21:30 tgl
Tom Lane <[EMAIL PROTECTED]> writes:
> Hardly --- how will you choose the best subplans if you don't calculate
> their costs?
Uhm, good point. but as you say not really a problem.
> I'm also a bit suspicious of the "it's all a linear equation" premise,
> because the fact of the matter is that th
On Sat, Oct 15, 2005 at 05:53:45PM -0400, Greg Stark wrote:
> Martijn van Oosterhout writes:
>
> > This is unfortunate because EXPLAIN ANALYZE is an immensly useful tool,
> > as far as it goes. I've pondered if some kind of userspace timing
> > mechanism could be introduced (possibly using builti
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > I would fear queries like
>
> > SELECT * from tab WHERE x IN (1,2,3) LIMIT 1
>
> > Which ought to be instantaneous would become potentially slow.
>
> Why? They certainly wouldn't be any slower than they are now.
Greg Stark <[EMAIL PROTECTED]> writes:
> If the optimizer didn't collapse the cost for each node into a single value
> and instead retained the individual parameters at each node it could bubble
> those values all the way up to the surface. Then use the configuration options
> like random_page_cost
Martijn van Oosterhout writes:
> This is unfortunate because EXPLAIN ANALYZE is an immensly useful tool,
> as far as it goes. I've pondered if some kind of userspace timing
> mechanism could be introduced (possibly using builtin CPU cycle
> counters) to reduce the cost. It does, however, remain a
Tom Lane <[EMAIL PROTECTED]> writes:
> More generally, I think that depending entirely on EXPLAIN ANALYZE
> numbers is a bad idea, because the overhead of EXPLAIN ANALYZE is both
> significant and variable depending on the plan structure. The numbers
> that I think we must capture are the top-le
Greg Stark <[EMAIL PROTECTED]> writes:
> I would fear queries like
> SELECT * from tab WHERE x IN (1,2,3) LIMIT 1
> Which ought to be instantaneous would become potentially slow.
Why? They certainly wouldn't be any slower than they are now.
regards, tom lane
-
Tom Lane <[EMAIL PROTECTED]> writes:
> It strikes me that now that we have the bitmap indexscan mechanism,
> it wouldn't be hard to do better. I'm thinking that IN should be
> converted to a ScalarArrayOpExpr, ie
>
> x = ANY (ARRAY[val1,val2,val3,val4,...])
>
> and then we could treat bot
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Andrew Dunstan wrote:
From time to time the suggestion crops up of allowing a DROP IF
EXISTS ... syntax. This seems not unreasonable, and I just spent a
few minutes looking at what might be involved.
What about "CREATE IF NOT EXISTS" (
Martijn van Oosterhout wrote:
> I don't see an easy way out. Half the system thinks backslashes are
> special and need expansion, the other half thinks forward slashes are
> option markers. This is really just a variation on the "space in
> filenames" issue in UNIX.
pg_config --pgxs is supposed to
Tom Lane wrote:
We know that DIE is a convenient, useful semantics because people keep
asking for it. I think CINE has no track record.
You have confirmed my initial instinct. I will get this done for 8.2.
cheers
andrew
---(end of broadcast)-
Martijn van Oosterhout writes:
> Read the comments in those files, they are generally very enlightening
> as to how it all works. Also, there are various README files in the
> directories which also provide additional info.
executor/README is a good place to start for the executor.
On Sat, Oct 15, 2005 at 10:19:44PM +0530, Anuj Tripathi wrote:
> Hi
> I am trying to add a query progress indicator in postgres.Being a
> novice to the code I need help on few topics.
> 1.Where can we keep such a progress indicator code ?
> 2.What is the exact structure of plan returned by the pl
Hi
I am trying to add a query progress indicator in postgres.Being a
novice to the code I need help on few topics.
1.Where can we keep such a progress indicator code ?
2.What is the exact structure of plan returned by the planner ?
3.Does the planner return the estimates calculated while decidi
--On Samstag, Oktober 15, 2005 17:20:06 +0200 Martijn van Oosterhout
wrote:
Although the
effect is obvious for functions, it seems to me that it would be cool
to make a CREATE OR REPLACE TABLE that simply does nothing if the table
already exists with the right format.
Hmm i don't think this
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Also, DIE does not need to lock the table afterwards because it won't
>> exist, but CINE needs to keep a lock until transaction commit.
> Right. That's one reason I thought of starting with the DIE case ;-)
That argument seems
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Rod Taylor wrote:
>> I would rather have a 'rollback or release savepoint' command which
>> would rollback to the savepoint if there was an error or release it
>> otherwise.
>>
>> This way any command or combination of commands could be aborted or
>> co
[EMAIL PROTECTED] writes:
> But doesn't "x IN (NULL)" already fail to ever match, similar to "x
> = NULL"? (Assuming that compatibility switch isn't enabled)
The case I'm worried about is "x IN (1,2,NULL)". This *can* match.
Also, it's supposed to return NULL (not FALSE) if it doesn't match.
So
On Fri, Oct 14, 2005 at 10:32:02PM -0300, Alvaro Herrera wrote:
> What about "CREATE IF NOT EXISTS" (CINE)? If we support DROP IF EXISTS
> (DIE), is the other one going to be supported too?
CINE already exists sortof, it's called CREATE OR REPLACE. Although the
effect is obvious for functions, it
Alvaro Herrera wrote:
Andrew Dunstan wrote:
From time to time the suggestion crops up of allowing a DROP IF EXISTS
... syntax. This seems not unreasonable, and I just spent a few minutes
looking at what might be involved.
What about "CREATE IF NOT EXISTS" (CINE)? If we support DRO
Rod Taylor wrote:
On Fri, 2005-10-14 at 20:29 -0400, Andrew Dunstan wrote:
From time to time the suggestion crops up of allowing a DROP IF EXISTS
... syntax. This seems not unreasonable, and I just spent a few minutes
looking at what might be involved. Especially in the case of a table,
On Fri, Oct 14, 2005 at 03:34:43PM -0500, Kevin Grittner wrote:
> Of course, if running with EXPLAIN ANALYZE significantly
> distorts the run time, the whole effort is doomed at the outset.
> Can you quantify the distortion you mention? Do you know
To do the calculations for EXPLAIN ANALYZE, Post
On Fri, Oct 14, 2005 at 07:09:17PM -0400, Tom Lane wrote:
> I wrote:
> > I'm thinking that IN should be
> > converted to a ScalarArrayOpExpr, ie
> > x = ANY (ARRAY[val1,val2,val3,val4,...])
> Actually, there is one little thing in the way of doing this: it'll
> fail if any of the IN-list elemen
Magnus,
Magnus Hagander wrote:
It should be fairly easy to write a LDAP "backend" to password
authentication using openldap, winldap or whatever ldap library is
available.
Before I start working on anything I'd like to check if a patch for this
would be accepted?
Also I was thinking about LDA
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>
| >
| > From time to time the suggestion crops up of allowing a DROP IF EXISTS
| > ... syntax. This seems not unreasonable, and I just spent a few minutes
| > looking at what might be involved.
>
> What about "CREATE IF NOT EX
30 matches
Mail list logo