On 03.10.2011 11:03, Philip Martin wrote:
> Branko Čibej writes:
>
>> On 02.09.2011 22:56, Greg Stein wrote:
>>> On Fri, Sep 2, 2011 at 13:18, Mark Phippard wrote:
Pardon my ignorance, but in a scenario like this where we want to just
change some of the indexes, aren't we able to just b
Branko Čibej writes:
> On 02.09.2011 22:56, Greg Stein wrote:
>> On Fri, Sep 2, 2011 at 13:18, Mark Phippard wrote:
>>> Pardon my ignorance, but in a scenario like this where we want to just
>>> change some of the indexes, aren't we able to just bump the WC format
>>> on the fly automatically?
On 10/02/2011 03:26 PM, Branko Čibej wrote:
On 02.09.2011 16:30, Philip Martin wrote:
Bert also suggests changing our other indices by adding wc_id and/or
local_relpath thus allowing them to be UNIQUE. Can anyone confirm that
UNIQUE indices are better?
Just imagine, if the UNIQUE constraint di
On 02.09.2011 22:56, Greg Stein wrote:
> On Fri, Sep 2, 2011 at 13:18, Mark Phippard wrote:
>> Pardon my ignorance, but in a scenario like this where we want to just
>> change some of the indexes, aren't we able to just bump the WC format
>> on the fly automatically? IOW, can't we just make a for
On 02.09.2011 16:30, Philip Martin wrote:
> Bert also suggests changing our other indices by adding wc_id and/or
> local_relpath thus allowing them to be UNIQUE. Can anyone confirm that
> UNIQUE indices are better?
Just imagine, if the UNIQUE constraint did not imply an index, every
INSERT or UPD
On Fri, Sep 2, 2011 at 18:32, Peter Samuelson wrote:
>
> [Greg Stein]
>> Since we are selecting only "current nodes" for each local_relpath,
>> then I presume we don't need the apr_hash_get() in there, correct?
>
> Yeah, I confirmed with him on IRC that the wc_db.c change (chiefly
> deleting the e
[Greg Stein]
> Since we are selecting only "current nodes" for each local_relpath,
> then I presume we don't need the apr_hash_get() in there, correct?
Yeah, I confirmed with him on IRC that the wc_db.c change (chiefly
deleting the extraneous apr_hash_get() call) is a cleanup that could be
applie
On Fri, Sep 2, 2011 at 12:35, Philip Martin wrote:
> Philip Martin writes:
>
>> The query STMT_SELECT_NODE_CHILDREN_WALKER_INFO as used in 1.7
>>
>> SELECT local_relpath, op_depth, presence, kind
>> FROM nodes
>> WHERE wc_id = ?1 AND parent_relpath = ?2
>> GROUP BY local_relpath
>>
On Fri, Sep 2, 2011 at 13:18, Mark Phippard wrote:
> Pardon my ignorance, but in a scenario like this where we want to just
> change some of the indexes, aren't we able to just bump the WC format
> on the fly automatically? IOW, can't we just make a format 30 with
> all these index changes and ha
On 09/02/2011 12:02 PM, Mark Phippard wrote:
On Fri, Sep 2, 2011 at 11:42 AM, Philip Martin
wrote:
Yes, that's why I think we can delete them. However we rarely write to
these tables so the overhead of having the superfluous index is
negligible. There is no real need to remove them from 1.7
Mark Phippard writes:
> Pardon my ignorance, but in a scenario like this where we want to just
> change some of the indexes, aren't we able to just bump the WC format
> on the fly automatically? IOW, can't we just make a format 30 with
> all these index changes and have it automatically upgrade
Pardon my ignorance, but in a scenario like this where we want to just
change some of the indexes, aren't we able to just bump the WC format
on the fly automatically? IOW, can't we just make a format 30 with
all these index changes and have it automatically upgrade any format
29 WC it comes across
Philip Martin writes:
> The query STMT_SELECT_NODE_CHILDREN_WALKER_INFO as used in 1.7
>
>SELECT local_relpath, op_depth, presence, kind
>FROM nodes
>WHERE wc_id = ?1 AND parent_relpath = ?2
>GROUP BY local_relpath
>ORDER BY op_depth DESC
>
> performs poorly and doesn't scale
> Mark Phippard wrote on Fri, Sep 02, 2011 at 12:02:02 -0400:
> > On Fri, Sep 2, 2011 at 11:42 AM, Philip Martin
> > wrote:
> > > Hyrum K Wright writes:
> > >
> > >> sqlite> select * from sqlite_master where type = 'index' and
> > >> tbl_name = 'WCROOT';
> > >> index|sqlite_autoindex_WCROOT_1
Mark Phippard wrote on Fri, Sep 02, 2011 at 12:02:02 -0400:
> On Fri, Sep 2, 2011 at 11:42 AM, Philip Martin
> wrote:
> > Hyrum K Wright writes:
> >
> >> sqlite> select * from sqlite_master where type = 'index' and
> >> tbl_name = 'WCROOT';
> >> index|sqlite_autoindex_WCROOT_1|WCROOT|8|
> >>
On Fri, Sep 2, 2011 at 11:42 AM, Philip Martin
wrote:
> Hyrum K Wright writes:
>
>> sqlite> select * from sqlite_master where type = 'index' and
>> tbl_name = 'WCROOT';
>> index|sqlite_autoindex_WCROOT_1|WCROOT|8|
>> index|I_LOCAL_ABSPATH|WCROOT|9|CREATE UNIQUE INDEX I_LOCAL_ABSPATH
>> ON W
Hyrum K Wright writes:
> sqlite> select * from sqlite_master where type = 'index' and
> tbl_name = 'WCROOT';
> index|sqlite_autoindex_WCROOT_1|WCROOT|8|
> index|I_LOCAL_ABSPATH|WCROOT|9|CREATE UNIQUE INDEX I_LOCAL_ABSPATH
> ON WCROOT (local_abspath)
>
> would both indicate there are two ind
On Fri, Sep 2, 2011 at 9:30 AM, Philip Martin
wrote:
> The query STMT_SELECT_NODE_CHILDREN_WALKER_INFO as used in 1.7
>
> SELECT local_relpath, op_depth, presence, kind
> FROM nodes
> WHERE wc_id = ?1 AND parent_relpath = ?2
> GROUP BY local_relpath
> ORDER BY op_depth DESC
>
> performs
"Bert Huijben" writes:
> Another option (good or bad) would be to just update the code to create
> format 29 working copies to create different indexes.
>
> Our use of SQL would ensure that we would get the same result with the old
> or new indexes, but working copies created with newer clients w
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: vrijdag 2 september 2011 16:30
> To: dev@subversion.apache.org
> Subject: SQL indices a WC format bump and 1.7
>
> The query STMT_SELECT_NODE_CHILDREN_WALKER_INFO as used in 1.7
>
>SELECT local_re
20 matches
Mail list logo
