Am 31.07.2006 um 19:08 schrieb Michael Stone:
I never saw a column description--that would certainly help. :) I
saw a schema, but not an explanation of what the elements do. From
what I can understand of what you're saying, it is sounding as
though the bacula.file table contains an entry f
On Mon, Jul 31, 2006 at 05:54:41PM +0200, Axel Rau wrote:
The file table is the biggest one, because it contains one row per
backup job and file (see my column description).
I never saw a column description--that would certainly help. :) I saw a
schema, but not an explanation of what the elem
Am 31.07.2006 um 15:53 schrieb Mark Lewis:
It seems like you might be able to avoid the expensive directory
lookups
entirely without changing the schema by defining an immutable function
dir_depth(path), which would just count the number of forward slashes.
Then create a functional index on d
Am 31.07.2006 um 17:54 schrieb Axel Rau:
Tweaking your query and omitting the RTRIM/REPLACE stuff, I get:
My example did not cover the case of empty subdirectories, in which
case your simplified query fails:
---
path | children
---
Am 31.07.2006 um 17:21 schrieb Michael Stone:
On Mon, Jul 31, 2006 at 05:06:00PM +0200, Axel Rau wrote:
Please reconsider your proposals with the above
I'm not sure what you're getting at; could you be more specific?
Let's see...
Am 31.07.2006 um 15:30 schrieb Michael Stone:
And then what
On Mon, Jul 31, 2006 at 05:06:00PM +0200, Axel Rau wrote:
Please reconsider your proposals with the above
I'm not sure what you're getting at; could you be more specific?
Mike Stone
---(end of broadcast)---
TIP 1: if posting/reading through Usen
Am 31.07.2006 um 15:30 schrieb Michael Stone:
If I understand the intend of this SQL,
Let me show the tables first:
Table "bacula.path"( 65031 rows)
Column | Type | Modifiers
+-
+-
It seems like you might be able to avoid the expensive directory lookups
entirely without changing the schema by defining an immutable function
dir_depth(path), which would just count the number of forward slashes.
Then create a functional index on dir_depth(path) and in the query do a
check for di
On Mon, Jul 31, 2006 at 01:54:24PM +0200, Axel Rau wrote:
Am 31.07.2006 um 13:15 schrieb Michael Stone:
On Mon, Jul 31, 2006 at 12:48:11PM +0200, Axel Rau wrote:
WHERE P.path ~ '^%@/[^/]*/$' ) AS NLPC
This can't be indexed. You might try something like WHERE P.path
LIKE '[EMAI
Am 31.07.2006 um 13:15 schrieb Michael Stone:
On Mon, Jul 31, 2006 at 12:48:11PM +0200, Axel Rau wrote:
WHERE P.path ~ '^%@/[^/]*/$' ) AS NLPC
This can't be indexed. You might try something like WHERE P.path
LIKE '[EMAIL PROTECTED]' AND P.path ~ '^%@/[^/]*/$'
Why does it qui
On Mon, Jul 31, 2006 at 12:48:11PM +0200, Axel Rau wrote:
WHERE P.path ~ '^%@/[^/]*/$' ) AS NLPC
This can't be indexed. You might try something like
WHERE P.path LIKE '[EMAIL PROTECTED]' AND P.path ~ '^%@/[^/]*/$'
The schema could be a lot more intelligent here. (E.g., store pa
Hi group,
this is a directory tree query for a backup system (http://
sourceforge.net/projects/bacula).
You provide a path and get back the names of the children plus a
boolean telling if the child has itself children.
The "%@" stands for the initial path:
12 matches
Mail list logo
