Ron Mayer wrote:
One use case that I think GIT would help a lot with are my
large address tables that are clustered by zip-code but
often queried by State, City, County, School District,
Police Beat, etc.
Yep, GIT would shrink the index on zip-code tremendously...
I imagine a GIT index on "st
On Sat, Apr 12, 2008 at 3:46 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> As an aside, you've reminded me about another thing that bothers me about
> Bugzilla and RT. In both cases they seem to put a lot of focus around the
> idea
> of "searching" bugs. I don't really get why.
>
Er, because
Heikki Linnakangas wrote:
* GIT (Grouped Index Tuple) indexes, which achieve index space savings
in btrees by having a single index tuple represent multiple heap tuples
[...]
Another issue is that we'd need to check how much of the use-case for
GIT has been taken over by HOT.
There is, however,
"PFC" <[EMAIL PROTECTED]> writes:
> But, using prepared statements with persistent connections is messy,
> because you never know if the connection is new or not, if it contains
> already
> prepared statements or not, you'd have to maintain a list of those statements
> (named) for every q
PFC <[EMAIL PROTECTED]> writes:
> And it is very easy to recognize a query we've seen before,
It's not so easy as all that. Consider search_path. Consider temp
tables.
The real problem here is entirely on the client side:
> But, using prepared statements with persistent connections
I think what he's referring to is persistently caching plans so that new
connections can use them. That makes a lot more sense if you have lots of
short-lived connections like a stock php server without persistent
connections
turned on or a connection pooler. You can prepare queries but they o
We use RT here for our trouble ticket system and the dashboard
can easily be configured to display tickets based on any search
criteria and you can have multiple views on the same screen.
The search functionality can be viewed as the tool for configuring
your views into the system, for whatever its
[EMAIL PROTECTED] (Tom Lane) writes:
> In short, I think it's time to declare our first commit fest done.
Congratulations!
As a pure observer in the matter, it has clearly been a somewhat
painful process, which must be tempered by the consideration that what
was being reviewed was pretty much a
Alvaro Herrera wrote:
> To implement this I propose keeping track of four additional pointers in
> SnapshotData: "next" and "prev" in the registered list, and "next" and
> "prev" in the active stack.
FWIW this does not work as proposed because one snapshot can be stored
as active more than once s
"TL" == Tom Lane writes:
TL> It's not wrong and it won't be removed. Please note the header
TL> comment in that file:
TL> * NOTE: this file should not be included into any non-snowball
TL> sources!
ok, i'll just include snowball/libstemmer/api.h or snowball/libstemmer/header.h
instead.
i
Vladimir Volovich <[EMAIL PROTECTED]> writes:
> but please remove the "#define free" from snowball/header.h because, as
> you said, it's wrong.
It's not wrong and it won't be removed. Please note the header comment
in that file:
* NOTE: this file should not be included into any non-snowball sou
Added to TODO:
* Allow functions to control the transaction state
http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php
---
Pavel Stehule wrote:
> Hello,
>
> I found lot of discus about this topic.
>
> htt
> I'm leaning towards removing RECHECK because it'll allow simplification
I vote to do it.
> I seem to recall that you had some plans for other incompatible changes
> in the call conventions for GIST/GIN support functions, too. If
Right now we suggest only new feature which just extent interface.
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> In short, I think it's time to declare our first commit fest done.
>
> > OK, todo updated, but what about the "Maintaining cluster order on
> > insert" idea?
> > http://momjian.us/cgi-bin/pgpatches
>
> The la
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In short, I think it's time to declare our first commit fest done.
> OK, todo updated, but what about the "Maintaining cluster order on
> insert" idea?
> http://momjian.us/cgi-bin/pgpatches
The last item I see in the thread is s
On Fri, Apr 11, 2008 at 9:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> To be blunt, that seems like a really bad idea, and I have not the
> slightest hesitation about breaking your ability to do it. How
> do you know that the recheck-need corresponds to what you are testing
> on the applicatio
Tom Lane wrote:
> What's left on Bruce's patch queue page is:
>
> * Finishing out Heikki's patch to allow runtime determination of the
> need to recheck an index condition. What's committed so far doesn't
> yet have any actual use :-(. Although I intend to keep working on
> that, it's clearly ne
On Fri, 11 Apr 2008, Tom Lane wrote:
Oleg Bartunov <[EMAIL PROTECTED]> writes:
Slightly offtopic. How to get benefit on tuple level ? For example,
we mark GiST tsearch index as lossy, while for not very big documents it's
actually exact and we could save a lot not rechecking them.
Won't that
"MvO" == Martijn van Oosterhout writes:
>> it worked fine with postgresql 8.2; with 8.3 it started segfaulting,
>> and it appeared that the reason is because in postgresql 8.3, the
>> "free" is a macro defined in snowball/header.h: #define free(a)
>> pfree(a)
MvO> It does seem wrong. Do you
On Apr 11, 2008, at 12:54 PM, Tom Lane wrote:
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
In Trac, if I just want to loosely associate several tickets together
I'd use *keywords*, e.g., put "index am" in the keywords list for
several tickets, and then they'll show up prominently when I search
for
On Fri, Apr 11, 2008 at 06:46:18PM +0100, Gregory Stark wrote:
> As an aside, you've reminded me about another thing that bothers me about
> Bugzilla and RT. In both cases they seem to put a lot of focus around the
> idea of "searching" bugs. I don't really get why.
To be fair to RT, it's really
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> Just wanted to point out that I personnally use the capability to
> remove the RECHECK of PostGIS opclass (I define a similar opclass
> without the recheck) when I enforce the SRID in the application:
To be blunt, that seems like a really bad idea, an
On Apr 10, 2008, at 4:48 PM, Gregory Stark wrote:
Well I feel like storing a query and resending it later is something
predictable which will work reliably. Storing a psql input line and
reinterpreting it later is surely going to cause weird things to
happen.
Just for some examples off the to
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> Slightly offtopic. How to get benefit on tuple level ? For example,
> we mark GiST tsearch index as lossy, while for not very big documents it's
> actually exact and we could save a lot not rechecking them.
Won't that just fall out of this? Assuming the
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Now we choose - save compatibility or not.
> We can save flag RECHECK and introduce optional needRecheck argument for
> consistent function and new opclass can use new interface, old ones will work
> with RECHECK. Or we remove RECHECK and force opclasse
On Fri, Apr 11, 2008 at 7:41 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Offhand I suspect
> only the PostGIS project would be affected.
Just wanted to point out that I personnally use the capability to
remove the RECHECK of PostGIS opclass (I define a similar opclass
without the recheck) when I e
What's left on Bruce's patch queue page is:
* Finishing out Heikki's patch to allow runtime determination of the
need to recheck an index condition. What's committed so far doesn't
yet have any actual use :-(. Although I intend to keep working on
that, it's clearly new development and hence not
Slightly offtopic. How to get benefit on tuple level ? For example,
we mark GiST tsearch index as lossy, while for not very big documents it's
actually exact and we could save a lot not rechecking them.
Oleg
On Fri, 11 Apr 2008, Teodor Sigaev wrote:
Teodor, do you have any thoughts about exact
Dickson dos Santos Guedes escribió:
> Well, working in the latest revision from CVS I added a feature for
> psql to the command "\d+", now it shows the object size as like as
> "\l+" show the database size.
>
Added to May commitfest page, thanks.
--
Alvaro Herrera
Don't we need to change the GiST/GIN support function interface anyway,
to be able to return the "recheck" flag?
Now we choose - save compatibility or not.
We can save flag RECHECK and introduce optional needRecheck argument for
consistent function and new opclass can use new interface, old one
Hi all,
I don't know if I can post a patch here (I did subscribe to
psql-patches but without success).
Well, working in the latest revision from CVS I added a feature for
psql to the command "\d+", now it shows the object size as like as
"\l+" show the database size.
I will be pretty glad with y
I can think of is that it'd break user-defined opclasses ... but it's
not like we don't change the API for GIST/GIN support functions from
time to time anyway. Does anyone have any idea how many people are
Hmm. The biggest breakage of interface to indexes was a removing
pg_am.amconcurrent flag -
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> PFC wrote:
>
>> So, where to go from that ? I don't see a way to implement this without
>> a (backwards-compatible) change to the wire protocol, because the clients
>> will want to specify when a plan should be cached or not. Since the user
>
Gregory Stark wrote:
As an aside, you've reminded me about another thing that bothers me about
Bugzilla and RT. In both cases they seem to put a lot of focus around the idea
of "searching" bugs. I don't really get why.
Maybe it makes sense if you plan to be like Mozilla and have 8-year-old bug
Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
RECHECK flag could be removed.
Hmm, that's slightly more radical than I was considering, but it would
simplify matters wouldn't it? The only strong argument against it that
I can think of is that it'd break user-defined opclasses ... b
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> In Trac, if I just want to loosely associate several tickets together
> I'd use *keywords*, e.g., put "index am" in the keywords list for
> several tickets, and then they'll show up prominently when I search
> for those terms.
Assuming you know what to
On Fri, 11 Apr 2008 18:46:18 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> I would think an interface which presents you with *all* unclosed
> bugs by default, perhaps organized in some way (keywords, milestones,
> etc) would be more conducive to getting attention to everything.
>
> I'm sure y
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> In Trac, if I just want to loosely associate several tickets together
> I'd use *keywords*, e.g., put "index am" in the keywords list for
> several tickets, and then they'll show up prominently when I search
> for those terms.
As an aside, you've remin
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> PFC wrote:
>> So, where to go from that ? I don't see a way to implement this without
>> a (backwards-compatible) change to the wire protocol, because the clients
>> will want to specify when a plan should be cached or not. Since the user
>> should n
[ Changing subject to draw people's attention ... ]
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> RECHECK flag could be removed.
Hmm, that's slightly more radical than I was considering, but it would
simplify matters wouldn't it? The only strong argument against it that
I can think of is that it'd
On Apr 11, 2008, at 9:30 AM, Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
Personally I don't think we *know* what we want to do and that's
why the wiki
is a good interim tool.
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting wit
I wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> I remember that last spring, in the context of GIT, you were worried
>> about the performance implication of preparing to recheck rows when no
>> rechecks are needed. I didn't quite buy that back then, but this would
>> have the same i
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting with tracking commit-fest issues.
A year from now, we might have enough experience to decide that some
more-rigidly-structured tool will do what we need, but we don't have
it today. We spent enough
On Sat, Apr 12, 2008 at 3:13 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > The bug trackers I've dealt with haven't got much flexibility in this
> > respect either --- the sorts of global views you can get are entirely
> > determined by the tool. I'm
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting with tracking commit-fest issues.
A year from now, we might have enough experience to decide that some
more-rigidly-structured tool will do what we need, but we don't have
it today. We spent enough
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The bug trackers I've dealt with haven't got much flexibility in this
> respect either --- the sorts of global views you can get are entirely
> determined by the tool. I'm fairly certain that a tracker designed around
> the assumption that different entries
PFC wrote:
> So, where to go from that ? I don't see a way to implement this without
> a (backwards-compatible) change to the wire protocol, because the clients
> will want to specify when a plan should be cached or not. Since the user
> should not have to name each and every one of the
Perhaps it would be better to initialize needRecheck to the opclass
RECHECK flag value? If the consistent function does nothing, the
behavior is the same as before, but it can flip the flag in either
direction if it wants.
I have not any objections. In this case (and preparing of rechecking i
(I've already said that I think the wiki is a great step forward,
FWIW, and I'm not in any way suggesting that we should just drop it
and pick my favorite issue tracker or anything. However, for those
interested in discussion about theoretical benefits and cons of the
different systems...)
On Fri,
Well, I realized the idea of global prepared statements actually sucked,
so I set on another approach thanks to ideas from this list, this is
caching query plans.
First, let's see if there is low hanging fruit with the typical small,
often-executed queries that are so frequent on website
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Perhaps it would be better to initialize needRecheck to the opclass
>> RECHECK flag value? If the consistent function does nothing, the
>> behavior is the same as before, but it can flip the flag in either
>> direction if it wants
Tom Lane wrote:
Perhaps it would be better to initialize needRecheck to the opclass
RECHECK flag value? If the consistent function does nothing, the
behavior is the same as before, but it can flip the flag in either
direction if it wants.
I remember that last spring, in the context of GIT, you
Marc G. Fournier wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> In the projects I'm involved in, tends to be for used for both purposes ...
> one
> central location for everything ...
Yea, good point. I think our big question is what justification do we
have for doing things d
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Personally I don't think we *know* what we want to do and that's why the
> > wiki
> > is a good interim tool.
>
> Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
> flexible way of experimenting with tracking comm
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> So, I planned to add pointer to bool to consistent method, so signature will
> be
> bool consistent( bool check[], StrategyNumber n, Datum query, bool
> *needRecheck)
> Returning value of needRecheck should be ignored for operation not marked by
> REC
Magnus Hagander <[EMAIL PROTECTED]> writes:
> It seems my fix for stat() broke cygwin, because it doesn't have
> dosmaperr() available.
Are you sure you aren't just missing an #include? The other places
where we call _dosmaperr don't seem to be protected by anything more
than #ifdef WIN32.
Gregory Stark <[EMAIL PROTECTED]> writes:
> Personally I don't think we *know* what we want to do and that's why the wiki
> is a good interim tool.
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost,
flexible way of experimenting with tracking commit-fest issues.
A year from now,
Gregory Stark escribió:
> Personally I don't think we *know* what we want to do and that's why the wiki
> is a good interim tool. We'll see what info we need there and who needs to
> fill it in and find out what tool will fit our needs.
+1. Let's learn what we need first, and find an appropriate
On Fri, 11 Apr 2008 15:44:43 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> Proposing specific tools without a consensus on what that process is
> putting the cart before the horse. You pick the tools to fit what you
> want to do. We haven't decided what we want to do yet.
>
> Personally I don'
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> The reason a tracker is better imo than a wiki is that a wiki still
> needs someone to maintain an index page (or multiple index pages for
> different queues), so there's still an opportunity for something to
> fall through.
For the umpteenth time bug
Teodor, do you have any thoughts about exactly how you'd fix @@@ ?
I suppose that the recheck-need is not really a property of specific
tuples, but of a particular query, for that case. Where would you
want to detect that?
tsquery may include restriction by weight of search terms: 'sea & port:A
On Fri, Apr 11, 2008 at 1:32 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > > The apache group seems to say the patches are indeed ignored, rather
> > > then just delayed --- for us, every patch does get a reply, however
> > > delayed.
> > >
> >
> > Bruce, I think that this comes back to
Hannu Krosing wrote:
A question to all pg hackers
Is anybody working on adding pipelining to set returning functions.
How much effort would it take ?
Where should I start digging ?
i asked myself basically the same question some time ago.
pipelining seems fairly impossible unless we ban j
Hannu Krosing wrote:
BTW, I'm pretty sure I have figured out the method for storing minimal
required binary tree as an array, where adding each page adds exactly
one upper node. The node added is often not the immediate parent, but is
always the one needed for covering all nodes.
I just have to
It seems my fix for stat() broke cygwin, because it doesn't have
dosmaperr() available. The way I see it there are two ways to fix this:
1) Don't apply the stat fix for cygwin.
2) Make our dosmaperr() function be used on cygwin.
I don't know if the fix is actually needed on cygwin. Can someone
On Fri, Apr 11, 2008 at 01:00:04PM +0300, Hannu Krosing wrote:
> > i asked myself basically the same question some time ago.
> > pipelining seems fairly impossible unless we ban joins on those
> > "plugins" completely.
>
> Not really, just they have to be "materialized" before joins, or
> streami
> >> ... 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
On Fri, 2008-04-11 at 10:57 +0200, Hans-Juergen Schoenig wrote:
> Hannu Krosing wrote:
> > A question to all pg hackers
> >
> > Is anybody working on adding pipelining to set returning functions.
> >
> > How much effort would it take ?
> >
> > Where should I start digging ?
> >
>
> i asked mys
"Bernd Helmle" <[EMAIL PROTECTED]> writes:
>> What happens to aliases when you change the encoding in the middle of
>> running one? Actually, come to think of it, what *does* happen to aliases
>> when the encoding changes??
>
> Hmm? What happens if you are going to change your encoding within mul
On Thu, Apr 10, 2008 at 07:28:29PM -0700, Vladimir Volovich wrote:
> it worked fine with postgresql 8.2; with 8.3 it started segfaulting, and
> it appeared that the reason is because in postgresql 8.3, the "free" is
> a macro defined in
> snowball/header.h:
> #define free(a) pfree(a)
It does seem
--On Donnerstag, April 10, 2008 22:48:24 +0100 Gregory Stark
<[EMAIL PROTECTED]> wrote:
Well I feel like storing a query and resending it later is something
predictable which will work reliably. Storing a psql input line and
reinterpreting it later is surely going to cause weird things to happe
Hi!
i'm using a module for postgresql (8.2 and 8.3) which links with a
3rd-party library and calls a function from there which returns a
malloc()'ed string.
[it's a libunac, and unac_string() but the question is general]
there was a pg_unac-8.2.tar.gz tarball distributed on the net, which has
th
Joshua D. Drake wrote:
> On Thu, 10 Apr 2008 23:23:20 -0400 (EDT)
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > Brendan Jurd wrote:
> > > I'm not saying Bruce is doing a bad job, far from it. I'm saying
> > > the job is impossible.
> > >
> > > I just wanted to correct the apparent impression
On Thu, 10 Apr 2008 23:23:20 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Brendan Jurd wrote:
> > I'm not saying Bruce is doing a bad job, far from it. I'm saying
> > the job is impossible.
> >
> > I just wanted to correct the apparent impression that "patches don't
> > get ignored her
On Thu, 10 Apr 2008 23:26:28 -0400
Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
>
> And then anybody asking a question about the status of something gives
> you a pedestal to show how nicely your tracker works.
>
If you think that is what I am after you obviously have no idea who are
you replying t
75 matches
Mail list logo
