On Sat, Jul 31, 2010 at 11:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Now, of the above the only cases where we'd be likely to be able to do
anything very useful with stats on the expression value are the name
case, which isn't that exciting in practice, and the tsvector cases.
For tsvector it
Tom Lane wrote:
Robert Haas writes:
I guess I'd appreciate it if someone could explain in more detail
in what cases we fail to collect stats.
[detailed description]
I don't think this can be claimed to be a corner case. If you set
up an FTS index according to the first alternative
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 31, 2010 at 11:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think this can be claimed to be a corner case. If you set up
an FTS index according to the first alternative offered in
I wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah, maybe you're right. But I'd still prefer to see us break the
ABI and do this just in 9.0 rather than changing 8.4.
OK, I can live with that. I'll take a look at it shortly.
Proposed patch attached (compiles, untested as yet).
* Tom Lane (t...@sss.pgh.pa.us) wrote:
After a bit of study of the code, it appears to me that it's not too
difficult to fix: we just have to use the expression's result type
rather than the index column's atttypid in the subsequent processing.
ANALYZE never actually looks at the index column
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
After a bit of study of the code, it appears to me that it's not too
difficult to fix: we just have to use the expression's result type
rather than the index column's atttypid in the subsequent processing.
ANALYZE
On Jul 31, 2010, at 11:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It's only been very recently that we had any useful stats capability
that could apply in such situations (in fact I think we still haven't
actually shipped a non-bogus version of tsvector typanalyze :-().
So I'm not sure anyone
Robert Haas robertmh...@gmail.com writes:
I think this whole discussion is starting with the wrong premise. This
is not a bug fix; therefore, it's 9.1 material.
Failing to store stats isn't a bug?
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Sat, Jul 31, 2010 at 12:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think this whole discussion is starting with the wrong premise. This
is not a bug fix; therefore, it's 9.1 material.
Failing to store stats isn't a bug?
Well, it kind of sounds
Robert Haas 07/31/10 12:33 PM
Tom Lane wrote:
Robert Haas writes:
I think this whole discussion is starting with the wrong premise.
This is not a bug fix; therefore, it's 9.1 material.
Failing to store stats isn't a bug?
Well, it kind of sounds more like you're removing a known
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Robert Haas 07/31/10 12:33 PM
Tom Lane wrote:
Failing to store stats isn't a bug?
Well, it kind of sounds more like you're removing a known
limitation than fixing a bug.
It's operating as designed and documented. There is
On Sat, Jul 31, 2010 at 9:16 PM, Stephen Frost sfr...@snowman.net wrote:
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Robert Haas 07/31/10 12:33 PM
Tom Lane wrote:
Failing to store stats isn't a bug?
Well, it kind of sounds more like you're removing a known
limitation than
Robert Haas robertmh...@gmail.com writes:
On Sat, Jul 31, 2010 at 9:16 PM, Stephen Frost sfr...@snowman.net wrote:
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Robert Haas 07/31/10 12:33 PM
Tom Lane wrote:
Failing to store stats isn't a bug?
Well, it kind of sounds more like
I've been poking at the FTS problem example recently submitted by
Artur Dabrowski. It contains an index declared like so:
CREATE INDEX idx_keywords_ger ON search_tab
USING gin (to_tsvector('german'::regconfig, keywords));
which can be queried like so
select * from search_tab where
14 matches
Mail list logo
