> I don't understand this if it's calling option 2 the monolithic
> implementation. I was intending that the values be permanent tokens if
> you like, so that ZERO rewriting would be required for any types of
> modification. So I don't see where locking comes in. I don't want
> rewriting either.
> > > * If there is not a version mismatch, psql tells you nothing but
> > > ask for help if you need it.
> >
> > That was NOT part of the agreement. The version line should stay.
>
> Why do we care, if the version matches? Not that I am feeling like
> fighting about it but it seems just a wa
> > The optimizer could then use a different (much lower) value of
> > random_page_cost for tables for which "cache priority" is set
> > highest since it would know.
>
> "cache priority" to me sounds like we're trying to influence caching
> behavior, which isn't what's happening. I do agree
Magnus Hagander wrote:
> I just tried the MSVC build on a system with ActiveState Perl 5.10,
and
> it doesn't work. Some quick debugging before I downgraded to 5.8
showed
> that this regexp in Project.pm line 262:
> my $replace_re = qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*:
)?\$(\([^\)]+\))\/(.*)\/[^\
> >> ... The really serious problem I've got with it is that
> >> it'd foreclose the possibility of returning actual index keys from
btree
> >> indexes, thus basically killing the usefulness of that idea. I'm
not
> >> convinced it would offer enough gain to be worth paying that price.
>
> > I do
> * GIT (Grouped Index Tuple) indexes, which achieve index space savings
> in btrees by having a single index tuple represent multiple heap
tuples
> (on a single heap page) containing a range of key values. I am not
sure
> what the development status is --- Heikki had submitted a completed
> patc
Tom wrote:
> So I'm of the opinion that there's no good reason to change either our
> code or our docs. The standard-incompatibility is with BEGIN, not
> SET TRANSACTION, and it's already documented.
Yes.
> PS: the proposed patch is buggy as can be anyway: it applies the
change
> even if !doit,
> > The closest analogy to what I'm thinking is the perl CPAN
> or ruby gems.
I think this is more a developer thing. I don't think an ISP would want
all that automagic (and certainly does not do that for joe user).
> One thing that might be worth looking at is an install command at the
> SQL
Heikki wrote:
> It seems that the worst case for this patch is a scan on a table that
> doesn't fit in shared_buffers, but is fully cached in the OS cache. In
> that case, the posix_fadvise calls would be a certain waste of time.
I think this is a misunderstanding, the fadvise is not issued to
> So, I finally decide to focus on the project idea of improving hash
> index now. It's more valuable , and also challenging.
>
> Any suggestion about the project idea of improving hash index?
Imho one thing to look into is the storage. I do not see any real value
in storing the key itself (espec
> > How about always adding the TID as last key when using qsort for
create
> > index ?
>
> I think you misunderstood: that's what we do now. I'm proposing
> removing it because I think it's probably useless.
Ah, sorry, I did not look at the code, and interpreted your comment as
some exceptional
> 2. If you've got lots of equal keys, it's conceivable that having the
> index entries sorted by TID offers some advantage in indexscan speed.
> I'm dubious that that's useful, mainly because the planner should
prefer
> a bitmap scan in such a case; and anyway the ordering is unlikely to
> be pre
> > Why is this not the default when supported?
>
> Fear.
>
> Maybe eventually, but right now I think it's too risky.
>
> One point that I already found out the hard way is that sizeof(off_t)
= 8
> does not guarantee the availability of largefile support; there can
also
> be filesystem-level co
> > Why is this not the default when supported? I am wondering both
from the
> > point of view of the user, and in terms of development direction.
>
> Also it would get more buildfarm coverage if it were default. If it
> breaks something we'll notice earlier.
No we don't, because the buildfar
14 matches
Mail list logo
