Re: directory tree query with big planner variation

Поиск
Список
Период
Сортировка
От Axel Rau
Тема Re: directory tree query with big planner variation
Дата
Msg-id 42955802-E96D-4199-9129-318F514FCDC6@Chaos1.DE
обсуждение исходный текст
Ответ на Re: directory tree query with big planner variation  (Michael Stone <mstone+postgres@mathom.us>)
Список pgsql-performance
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 for the subdirectory
> itself as well as entries for each file in the subdirectory?
It is the junction relation between path and filename and job and
describes
1. which files (identified by bacula.filename) are in a directory
(identified by bacula.path)
2. For each of those files they record a snapshot with
characteristics (lstat [base64 encoded], md5-checksum and a backup-
job [via jobid], which itself has backup-time etc.)
> And the reason you need to join back to the filename table is that
> there may be multiple copies of the filename from multiple backups?
One entry per backup(job) for each bacula.path/bacula.filename pair
in bacula.file.
> Does the subdirectory itself have an entry in the filename table?
Yes. Directories reference an entry containing '' in
bacula.filename.name.
> What is the content of the lstat column
File status info -- see stat(2).
> ; can it be used to distinguish a file from a directory?
Yes, the S_IFDIR bit identifies directories, but the whole lstat
column is base64 encoded
> Similarly for the md5 column--what would it contain for a directory?
It seems to contain 0.

Axel
Axel Rau, ☀Frankfurt , Germany                       +49-69-951418-0



В списке pgsql-performance по дате отправления:

Предыдущее
От: Michael Stone
Дата:
Сообщение: Re: directory tree query with big planner variation
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Performances with new Intel Core* processors