On Min, 2010-05-30 at 00:44 -0400, Andrew Dunstan wrote:
>
> Mohammad Heykal Abdillah wrote:
> > Hi all,
> >
> > Right now i am trying to understand how SQL parser is work.
> >
> > My question is there anyway to get list of table name and its atribut
> > before raw parser is analyze?
> >
> > Bec
Mohammad Heykal Abdillah wrote:
Hi all,
Right now i am trying to understand how SQL parser is work.
My question is there anyway to get list of table name and its atribut
before raw parser is analyze?
Because i like to understand how PostgreSQL "break-down" the asterik at
target list, speci
On Sat, May 29, 2010 at 11:40 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, May 29, 2010 at 6:11 PM, Tom Lane wrote:
>>> Or, to put it differently: if nobody's done that in the past twenty
>>> years, why is it likely to happen before 9.1?
>
>> Hmm. Well suppose we bet a dollar on whether
Greg Stark writes:
> On Sun, May 30, 2010 at 3:56 AM, Greg Stark wrote:
>> This sounds familiar. If you search back in the archives around 2004
>> or so I think you'll find a similar discussion when we replaced the
>> crc32 implementation with what we have now.
> Fwiw here's the thread (from 200
Robert Haas writes:
> On Sat, May 29, 2010 at 6:11 PM, Tom Lane wrote:
>> Or, to put it differently: if nobody's done that in the past twenty
>> years, why is it likely to happen before 9.1?
> Hmm. Well suppose we bet a dollar on whether that will happen or not.
> In fact, if you promise not t
Hi all,
Right now i am trying to understand how SQL parser is work.
My question is there anyway to get list of table name and its atribut
before raw parser is analyze?
Because i like to understand how PostgreSQL "break-down" the asterik at
target list, specialy in "natural join" case where Post
On Sat, May 29, 2010 at 5:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> Thoughts on a few of the remaining items:
>
>> Should we revert the default output format for bytea to the old style
>> before shipping 9.0.0? - Consensus seems to be "no", thus no action is
>> required.
>
> I think we shou
On Fri, May 28, 2010 at 11:12 AM, Fujii Masao wrote:
> On Thu, May 27, 2010 at 11:13 PM, Robert Haas wrote:
>>> I guess this happens because the frequency of checkpoint on the standby is
>>> too lower than that on the master. In the master, checkpoint occurs for
>>> every
>>> consumption of thre
On Sun, May 30, 2010 at 3:56 AM, Greg Stark wrote:
> This sounds familiar. If you search back in the archives around 2004
> or so I think you'll find a similar discussion when we replaced the
> crc32 implementation with what we have now.
Fwiw here's the thread (from 2005):
http://thread.gmane.or
This sounds familiar. If you search back in the archives around 2004
or so I think you'll find a similar discussion when we replaced the
crc32 implementation with what we have now. We put a fair amount of
effort into searching for faster implementations so if you've found
one 3x faster I'm pretty s
On Sat, May 29, 2010 at 6:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> The only disadvantage I see of just documenting this is that someone
>> might write a user-defined index opclass that works like this, and
>> they won't be able to use this until at least 9.1 (or at least, not
>> without pa
Added to TODO:
Consider a faster CRC32 algorithm
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01112.php
---
Andres Freund wrote:
> Hi,
>
> I started to analyze XLogInsert because
Robert Haas wrote:
> On Sat, May 22, 2010 at 4:53 PM, C?dric Villemain
> wrote:
> > 2010/5/21 Jan Wieck :
> >> The original idea was that a trusted language does not allow an
> >> unprivileged
> >> user to gain access to any object or data, he does not have access to
> >> without that language.
>
> > Wait. This works fine for me with stock pg_trgm. local is C and
> > encoding is UTF8. What version of PostgreSQL are you using? Mine is
> > 8.4.4.
>
> This is in 9.0, because 8.4 doesn't recognize the \u escape syntax. If
> you run this in 8.4, you're just comparing a sequence of ASCII letter
> This is still ignoring the point: arbitrarily changing the module's
> longstanding standard behavior isn't acceptable. You need to provide
> a way for the user to control the behavior. (Once you've done that,
> I think it can be just either "alnum" or "!isspace", but maybe some
> other behavior
On Wed, May 26, 2010 at 6:25 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> There might be some value in psql backslash command tests that
>> are designed to depend on just one or a few tables (or other appropriate
>> objects).
>
> Updated, much much smaller, patch attached.
On Sat, May 29, 2010 at 06:11:57PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > The only disadvantage I see of just documenting this is that
> > someone might write a user-defined index opclass that works like
> > this, and they won't be able to use this until at least 9.1 (or at
> > least, no
Robert Haas writes:
> The only disadvantage I see of just documenting this is that someone
> might write a user-defined index opclass that works like this, and
> they won't be able to use this until at least 9.1 (or at least, not
> without patching the source).
I don't actually think that anyone'
On Fri, May 28, 2010 at 10:32 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Jeff Davis writes:
>> > Currently, the check for exclusion constraints performs a sanity check
>> > that's slightly too strict -- it assumes that a tuple will conflict with
>> > itself. That is not always the case: the op
Robert Haas writes:
> Thoughts on a few of the remaining items:
> Should we revert the default output format for bytea to the old style
> before shipping 9.0.0? - Consensus seems to be "no", thus no action is
> required.
I think we should leave that there for awhile, though I agree it's
likely t
On Sat, May 29, 2010 at 5:09 PM, Robert Haas wrote:
> This is a really short list.
Thoughts on a few of the remaining items:
Type Mismatch Error in Set Returning Functions - tgl says this is a
deliberate change per link I just added to the wiki. do we think more
is required here to prevent cran
Robert Haas writes:
> This is still on the 9.0 open items list, but ISTM you fixed it with
> two commits on May 27th. Is that correct?
Oh, sorry, forgot to update the open items. Done now.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Sat, May 29, 2010 at 4:19 PM, Bruce Momjian wrote:
> Assuming we want a release Postgres 9.0 by mid-August, here is how the
> timetable would look:
>
> Need RC release to be stable for 1-2 weeks before final
> RC must be released by August 1
> Beta must be stable fo
On Mon, May 17, 2010 at 9:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, May 17, 2010 at 4:01 PM, Tom Lane wrote:
>>> Perhaps this is a backpatchable bug fix. Comments?
>
>> I can't say whether this is safe enough to back-patch, but the way
>> this is set up, don't we also need to fix
Assuming we want a release Postgres 9.0 by mid-August, here is how the
timetable would look:
Need RC release to be stable for 1-2 weeks before final
RC must be released by August 1
Beta must be stable for 2-3 weeks before RC
Stable beta must be relea
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> [ e of ] s/2 or s/3 look reasonable.
The examples in the LC paper seem to all use e = s/10. Note the stated
assumption e << s.
> So, should I just write a patch that sets the bucket width and pruning
> count using 0.07 as the assumed frequency of the m
On 29/05/10 17:34, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> On 29/05/10 17:09, Tom Lane wrote:
>>> There is definitely something wrong with your math there. It's not
>>> possible for the 100'th most common word to have a frequency as high
>>> as 0.06 --- the ones above it pre
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> On 29/05/10 17:09, Tom Lane wrote:
>> There is definitely something wrong with your math there. It's not
>> possible for the 100'th most common word to have a frequency as high
>> as 0.06 --- the ones above it presumably have larger frequencies,
>> which
On 29/05/10 17:09, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> Now I tried to substitute some numbers there, and so assuming the
>> English language has ~1e6 words H(W) is around 6.5. Let's assume the
>> statistics target to be 100.
>
>> I chose s as 1/(st + 10)*H(W) because the
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> Hm, I am now thinking that maybe this theory is flawed, because tsvecors
> contain only *unique* words, and Zipf's law is talking about words in
> documents in general. Normally a word like "the" would appear lots of
> times in a document, but (even ignor
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> Now I tried to substitute some numbers there, and so assuming the
> English language has ~1e6 words H(W) is around 6.5. Let's assume the
> statistics target to be 100.
> I chose s as 1/(st + 10)*H(W) because the top 10 English words will most
> probably
Tatsuo Ishii writes:
> After thinking a little bit more, I think following patch would not
> break existing behavior and also adopts mutibyte + C locale case. What
> do you think?
This is still ignoring the point: arbitrarily changing the module's
longstanding standard behavior isn't acceptable.
On Sat, May 29, 2010 at 9:13 AM, Tatsuo Ishii wrote:
> ! #define iswordchr(c) (lc_ctype_is_c()? \
> ! ((*(c) &
> 0x80)? !t_isspace(c) : (t_isalpha(c) || t_isdigit(c))) : \
>
Surely isspace(c) will always be false for non-ascii charac
On 29/05/10 12:34, Jesper Krogh wrote:
> On 2010-05-28 23:47, Jan Urbański wrote:
>> On 28/05/10 22:22, Tom Lane wrote:
>> Now I tried to substitute some numbers there, and so assuming the
>> English language has ~1e6 words H(W) is around 6.5. Let's assume the
>> statistics target to be 100.
>>
>>
Hi.
There seems to be an "unimplemented" area around getting statistics for
wildcard searches done. Wildcards anchored to the left can be matched
up by the gin-index and the ts_match_vq operator:
testdb=# select to_tsvector('project') @@ to_tsquery('proj:*');
?column?
--
t
(1 row)
Se
On 2010-05-28 04:47, Tom Lane wrote:
Cranking up the stats target actually makes it worse not better, since
low-frequency items are then more likely to get into the MCV list
I should have been more precise in the wording. Cranking up the
stats target gave me overall a "better plan", but tha
On 2010-05-28 23:47, Jan Urbański wrote:
On 28/05/10 22:22, Tom Lane wrote:
The idea that I was toying with is to assume a Zipfian distribution of
the input (with some reasonable parameter), and use that to estimate
what the frequency of the K'th element will be, where K is the target
number
> > It's not a practical solution for people working with prebuilt Postgres
> > versions, which is most people. I don't object to finding a way to
> > provide a "not-space" behavior instead of an "is-alnum" behavior,
> > but as noted upthread a GUC isn't the right way. How do you feel
> > about a
38 matches
Mail list logo
