Jeffrey Baker wrote:
Would you take a patch that retained the optimized executions of plans
returning 1 tuple and also fixed the random heap problem?
Can you elaborate on what you're proposing? Obviously sorted b+-tree
output is important for a lot more than just min()/max(). I don't see an
obvi
Tom Lane wrote:
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
I see that Tom has already done the infrastructure work by adding
getmulti, but getmulti isn't used by nodeIndexscan.c, only
nodeBitmapIndexscan.c. Will btree index scans be executed by creating
in-memory bitmaps in 8.1, or will some s
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> I see that Tom has already done the infrastructure work by adding
> getmulti, but getmulti isn't used by nodeIndexscan.c, only
> nodeBitmapIndexscan.c. Will btree index scans be executed by creating
> in-memory bitmaps in 8.1, or will some scans sti
On Sun, May 15, 2005 at 04:44:57PM +0800, Christopher Kings-Lynne wrote:
> Looks like hierarchical queries are now officially stalled :(
>
> Anyone want to take this up for 8.1?
Sergei and Jason,
Feel like taking SQL:1999 WITH RECURSIVE? It would be a giant help to
the PostgreSQL community. :)
About this time last year I was holding forth on the value of visiting
the heap in TID order, even when index scan tuples are randomly ordered.
Today I decided to start working on the problem stated in this TODO
item:
Fetch heap pages matching index entries in sequential order
On Sun, May 15, 2005 at 05:48:56PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Additionally we need to think what should happen if the user is the
> > grantor of some privilege. I think we should warn in RESTRICT mode, and
> > in CASCADE, revoke the privilege from the g
I suppose you are running on some BSD variant? BSD is notorious for
promising more than it can deliver with respect to number of open files
per process. This is a kernel bug, not a Postgres bug.
You can adjust Postgres' max_files_per_process setting to compensate for
the kernel's lying about its
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Additionally we need to think what should happen if the user is the
> grantor of some privilege. I think we should warn in RESTRICT mode, and
> in CASCADE, revoke the privilege from the grantee.
You mean "fail in RESTRICT mode", no?
> Hmm. We could i
On Sun, 2005-05-15 at 15:09 -0400, Tom Lane wrote:
> I'm planning to change ExecRestrPos and the routines it calls so that
> an updated TupleTableSlot holding the restored-to tuple is explicitly
> returned.
>
> Currently, since nothing is explicitly done to the result Slot of a
> plan node when we
[Moved to -hackers]
On Sat, May 14, 2005 at 11:32:23AM -0400, Tom Lane wrote:
> So what we've got [for DROP USER] is:
>
> 1. Reject if any references to user from within other databases
> (implementation restriction).
>
> 2. Reject if user owns any databases or tablespaces (safety feature).
>
I wrote:
> Currently, since nothing is explicitly done to the result Slot of a
> plan node when we restore its position, you might think that the Slot
> still points at the tuple that was current just before the Restore.
> You'd be wrong though, at least for seqscan and indexscan plans
> (I haven't
On Sun, 15 May 2005, Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
Bruce Momjian writes:
Hmm. That particular case will work, but the planner believes that only
consecutive columns in the index are usable --- that is, if you have
quals for a and c but not for b, it will think that the co
Greg Stark <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>>> Hmm. That particular case will work, but the planner believes that only
>>> consecutive columns in the index are usable --- that is, if you have
>>> quals for a and c but not for b, it will think that the condition for c
>>> isn't
On Thu, 12 May 2005 17:40:06 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>the planner believes that only
>consecutive columns in the index are usable --- that is, if you have
>quals for a and c but not for b, it will think that the condition for c
>isn't usable with the index. This is true for btre
On Wed, 4 May 2005 21:37:40 -0700, Josh Berkus
wrote:
>As stated above, these system views, once incorporated into a pg distribution,
>are likely to be with us *forever*.
I don't think that this is doable. :-(
You might want to put the system views into a version specific schema,
say pg_views8
Bruce Momjian writes:
> > Hmm. That particular case will work, but the planner believes that only
> > consecutive columns in the index are usable --- that is, if you have
> > quals for a and c but not for b, it will think that the condition for c
> > isn't usable with the index. This is true fo
I'm planning to change ExecRestrPos and the routines it calls so that
an updated TupleTableSlot holding the restored-to tuple is explicitly
returned.
Currently, since nothing is explicitly done to the result Slot of a
plan node when we restore its position, you might think that the Slot
still poin
Looks like hierarchical queries are now officially stalled :(
Anyone want to take this up for 8.1?
Chris
Original Message
Subject: Re: [HACKERS] SQL99 Hierarchical queries
Date: Sun, 15 May 2005 07:31:16 +0400
From: Evgen Potemkin <[EMAIL PROTECTED]>
Reply-To: Evgen Potemkin <[EMA
18 matches
Mail list logo
