From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Madison Kelly <linux(at)alteeve(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Need suggestion high-level suggestion on how to solve a performance problem |
Date: | 2005-07-08 01:04:28 |
Message-ID: | 200507071804.29189.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Madison,
> The problem comes when the user toggles a directory branch's backup
> flag (a simple check box beside the directory name). If it's a directory
> near the end of a branch it is fast enough. If they toggle a single file
> it is nearly instant. However if they toggle say the root directory, so
> every file and directory below it needs to be updated, it can take
> 500-600sec to return. Obviously this is no good.
>
> What I need is a scheme for being able to say, essentially:
>
> UPDATE file_info_1 SET file_backup='t' WHERE file_parent_dir~'^/';
Well, from the sound of it the problem is not selecting the files to be
updated, it's updating them.
What I would do, personally, is *not* store an update flag for each file.
Instead, I would store the update flag for the directory which was
selected. If users want to exclude certain files and subdirectories, I'd
also include a dont_update flag. When it's time to back up, you simply
check the tree for the most immediate update or don't update flag above
each file.
For the table itself, I'd consider using ltree for the directory tree
structure. It has some nice features which makes it siginifcanly better
than using a delimited text field.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Stuart Bishop | 2005-07-08 01:32:40 | Mount database on RAM disk? |
Previous Message | PFC | 2005-07-07 23:58:46 | Re: Need suggestion high-level suggestion on how to solve a performance problem |