Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Um, I don't believe we do any case-insensitive search now, do we?
No, I don't suppose we do.. I was thinking we ran quote_ident() on the
search-string side, but apparently we don't, meaning:
select * from TE
doesn't find 'test'. I suppose it's alr
On Tue, Aug 21, 2012 at 1:52 PM, Tom Lane wrote:
> In short, I think we might be able to make this fast, and more usable,
> just with hacking on psql's query generation rules. There's no need for
> server-side changes.
So, I think that hacking on psql's query generation rules may well be
a good
Robert Haas writes:
> So, I think that hacking on psql's query generation rules may well be
> a good idea, but shouldn't we also be bumping procost for the
> pg_whatever_is_visible functions? I mean, Stephen's information
> suggests that those values are pretty clearly wrong, regardless of
> anyt
Tom Lane wrote:
> We'd still emit quote_ident output, which means that if you did
>
> select * from TE
>
> it would change that to
>
> select * from "TEST
>
> (assuming you had say TEST1 and TEST2 so it couldn't complete
> further).
> if the word-so-far has a leading quote and
Stephen Frost writes:
> That's the kind of concern that I was expecting, to be honest. :) As
> Kevin's pointed out, it's not likely to be needed anyway.. There's a
> bit of an open question still regarding case-insensitive searching, but
> perhaps we let that be slow and only done if we don't ge
Stephen Frost writes:
> There's a couple of other interesting corner cases, such as:
Yeah. I had been thinking of this as purely a performance issue, but
if we want to consider adjusting the visible behavior as well, that
makes it a completely different thing.
> select * from "spa
> Will return
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> The LIKE idea is interesting. What you'd still need is to suppress the
> quote_ident function call so that it becomes just "relname LIKE 'foo%'".
> Which seems do-able if possibly rather ugly. That would leave us with
> SELECT ... FROM foo being fast but S
Stephen Frost writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Is this a regression versus earlier releases, or just a bad thing in general?
> Alright, so, yea, the commit I was referring to is this one:
> e84487f67a0d216f3db87b2558f1edd322a09e48
> Which was apparently in the 8.3 dev cyc
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Um ... I don't see any difference in the clause ordering from 8.2
> forward. "SELECT * FROM baz" produces a query like this in 8.2:
Odd.. I could have sworn I saw a difference in the query generated,
but perhaps I just assumed it was reordered, since it e
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> That already seems to work for me.
Ah, yes, that does.. I was using the query from tab-complete.c, which
wraps it in quote_ident(c.relanme), which ends up preventing us from
using the index.
There's a couple of other interesting corner case
Stephen Frost writes:
> * Stephen Frost (sfr...@snowman.net) wrote:
>>> Is this a regression versus earlier releases, or just a bad thing in
>>> general?
>> It's really a regression- in prior releases
> Sorry, to clarify (after reading through my -hackers inbox a bit more
> and realizing you we
Stephen Frost wrote:
> Would people accept adding an index on pg_class.relname to support
> fast tab-completion? Or is this going to expand into figuring out
> how to support index-based partial lookups for the 'name' type, so
> we could use the existing index (if that's even possible
> to do..
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Aug 16, 2012 at 10:37 PM, Stephen Frost wrote:
> > When doing tab-completion under 9.1, pg_table_is_visible(oid) is slow
> > and is ending up as the first thing tested against all the rows
> > in pg_class. Increasing the cost of pg_tabl
* Stephen Frost (sfr...@snowman.net) wrote:
> > Is this a regression versus earlier releases, or just a bad thing in
> > general?
>
> It's really a regression- in prior releases
Sorry, to clarify (after reading through my -hackers inbox a bit more
and realizing you were probably asking about 9.2
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Aug 16, 2012 at 10:37 PM, Stephen Frost wrote:
> > When doing tab-completion under 9.1, pg_table_is_visible(oid) is slow
> > and is ending up as the first thing tested against all the rows
> > in pg_class. Increasing the cost o
On Thu, Aug 16, 2012 at 10:37 PM, Stephen Frost wrote:
> Greetings,
>
> When doing tab-completion under 9.1, pg_table_is_visible(oid) is slow
> and is ending up as the first thing tested against all the rows
> in pg_class. Increasing the cost of pg_table_is_visible() up to
> 10 causes it
16 matches
Mail list logo
