Robert Haas writes:
> But, looking at it a bit more carefully, isn't the maximum-size logic
> for numeric rather bogus?
Perhaps, but I think you're confused on at least one point.
numeric(2,1) has to be able to hold 2 decimal digits, not 2
NumericDigits (which'd actually be 8 decimal digits given
On Thu, Jul 29, 2010 at 5:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> Did you look at the
>> patch to move the numeric stuff out of the .h file that I attached a
>> few emails back? If that looks OK, I can commit it and then redo the
>> rest of this along the lines we've discussed.
>
> A cou
The patch is in context diff format and applies cleanly. No doc
changes were included. Arguably there should be a mention in the
documentation for psql's \d+ commend, but since the number of child
tables and the display of reloptions aren't mentioned, perhaps we're
not trying to list *all* the di
Dave Page writes:
> We had a report of the above error from a pgAdmin user testing
> 1.12.0b3 with PG 9.0b3. The (highly simplified) query below works fine
> as a superuser:
> SELECT pg_get_expr(proargdefaults, 'pg_catalog.pg_class'::regclass)
> FROM pg_proc pr
> LEFT OUTER JOIN pg_descriptio
Robert Haas writes:
> Did you look at the
> patch to move the numeric stuff out of the .h file that I attached a
> few emails back? If that looks OK, I can commit it and then redo the
> rest of this along the lines we've discussed.
A couple of thoughts:
* It'd be good to get NUMERIC_HDRSZ out o
2010/7/29 Josh Berkus :
>
>> Do you think I should ask somewhere else?
>> Any hint?
>
> I might suggest asking on the pgsql-performance mailing list instead.
> You'll get *lots* more speculation there. However, the only way you're
> really going to know is to test.
Or maybe checking against the s
On Thu, Jul 29, 2010 at 5:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> OK. I think you're misinterpreting the point of that comment, which
>> may mean that it needs some clarification. By "the two byte header
>> format is also used", I think I really meant "the header (and in fact
>> the ent
Robert Haas writes:
> OK. I think you're misinterpreting the point of that comment, which
> may mean that it needs some clarification. By "the two byte header
> format is also used", I think I really meant "the header (and in fact
> the entire value) is just 2 bytes". Really, the low order bits
On Wed, Jul 28, 2010 at 11:51 AM, Boxuan Zhai wrote:
> I have fixed the action qual problem. Now the system can run merge command,
> with quals.
>
> I create a clean patch file (no debug clauses). See the attachment.
>
> Please try this new command if you have interest.
So, I tried this today, bu
On Thu, July 29, 2010 22:43, Erik Rijkers wrote:
> Hi Pavel,
>
> In xfunc.sgml, I came across a function example (for use of VARIADIC in
> polymorphic functions),
> where the function name is concat(): (in the manual: 35.4.10. Polymorphic
> SQL Functions).
> Although that is not strictly wrong,
On Thu, Jul 29, 2010 at 4:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 29, 2010 at 1:20 PM, Tom Lane wrote:
>>> On-disk is what I'm thinking about. Right now, a NaN's first word is
>>> all dscale except the sign bits. You're proposing to change that
>>> but I think it's unnecess
Hi Pavel,
In xfunc.sgml, I came across a function example (for use of VARIADIC in
polymorphic functions),
where the function name is concat(): (in the manual: 35.4.10. Polymorphic SQL
Functions).
Although that is not strictly wrong, it seems better to change that name when
concat goes into
co
Robert Haas writes:
> On Thu, Jul 29, 2010 at 1:20 PM, Tom Lane wrote:
>> On-disk is what I'm thinking about. Right now, a NaN's first word is
>> all dscale except the sign bits. You're proposing to change that
>> but I think it's unnecessary to do so.
> *Where* am I proposing this?
Um, your
On Wed, Jul 21, 2010 at 5:59 PM, Robert Haas wrote:
> On Wed, Jul 21, 2010 at 2:47 PM, Alexander Korotkov
> wrote:
>> On Wed, Jul 21, 2010 at 10:25 PM, Robert Haas wrote:
>>>
>>> *scratches head* Aren't you just moving the same call to a different
>>> place?
>>
>> So, where you can find this di
> Do you think I should ask somewhere else?
> Any hint?
I might suggest asking on the pgsql-performance mailing list instead.
You'll get *lots* more speculation there. However, the only way you're
really going to know is to test.
--
-- Josh Berkus
On Wed, Jul 28, 2010 at 1:20 AM, Mike Lewis wrote:
>>
>> > 1. As-is, it's a significant *pessimization* for small arrays, because
>> > the heap_tuple_untoast_attr_slice code does a palloc/copy even when one
>> > is not needed because the data is already not toasted. I think there
>> > needs to be
On Thu, Jul 29, 2010 at 1:20 PM, Tom Lane wrote:
> Yeah, you would need an additional layer of struct to represent the
> numeric with a length word in front of it. I think this is not
> necessarily bad because it would perhaps open the door to working
> directly with short-varlena-header values,
On Thu, 2010-07-29 at 19:52 +0200, Vincenzo Romano wrote:
> 2010/7/29 Joshua D. Drake :
> > On Thu, 2010-07-29 at 19:34 +0200, Vincenzo Romano wrote:
> >
> >> I expect that a more complex schema will imply higher workloads
> >> on the query planner. What I don't know is how the increase in the
> >>
2010/7/29 Joshua D. Drake :
> On Thu, 2010-07-29 at 19:34 +0200, Vincenzo Romano wrote:
>
>> I expect that a more complex schema will imply higher workloads
>> on the query planner. What I don't know is how the increase in the
>> workload will happen: linearly, sublinearly, polynomially or what?
D
On Thu, 2010-07-29 at 19:34 +0200, Vincenzo Romano wrote:
> I expect that a more complex schema will imply higher workloads
> on the query planner. What I don't know is how the increase in the
> workload will happen: linearly, sublinearly, polinomially or what?
>
> Significant testing would requi
2010/7/29 Joshua D. Drake :
> On Thu, 2010-07-29 at 19:08 +0200, Vincenzo Romano wrote:
>> Hi all.
>> I'm wondering about PGSQL scalability.
>> In particular I have two main topics in my mind:
>>
>> 1. What'd be the behavior of the query planner in the case I have
>> a single huge table with hundre
On Thu, Jul 29, 2010 at 1:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 29, 2010 at 1:00 PM, Tom Lane wrote:
>>> Or we could decide that volatile domain CHECK expressions are un-sensible
>>> and just relabel all these input functions as stable, which would make
>>> everything consi
Robert Haas writes:
> On Wed, Jul 28, 2010 at 3:00 PM, Tom Lane wrote:
>> No, you can do something like this:
>>
>> typedef union numeric
>> {
>>uint16 word1;
>>numeric_short short;
>>numeric_longlong;
>> } numeric;
> That doesn't quite work because there's also a
On Thu, 2010-07-29 at 19:08 +0200, Vincenzo Romano wrote:
> Hi all.
> I'm wondering about PGSQL scalability.
> In particular I have two main topics in my mind:
>
> 1. What'd be the behavior of the query planner in the case I have
> a single huge table with hundreds or thousands of partial indexes
Robert Haas writes:
> On Thu, Jul 29, 2010 at 1:00 PM, Tom Lane wrote:
>> Or we could decide that volatile domain CHECK expressions are un-sensible
>> and just relabel all these input functions as stable, which would make
>> everything consistent. Thoughts?
> Aren't volatile CHECK expressions p
Hi all.
I'm wondering about PGSQL scalability.
In particular I have two main topics in my mind:
1. What'd be the behavior of the query planner in the case I have
a single huge table with hundreds or thousands of partial indexes
(just differing by the WHERE clause).
This is an idea of mine to make
On Thu, Jul 29, 2010 at 1:00 PM, Tom Lane wrote:
> I wrote:
>> BTW, the situation on the input side is a bit different: record_in is
>> volatile because domain_in is, and I think we'd better leave that alone
>> since it's not too hard to believe that a domain might have volatile
>> CHECK expressio
On Wed, Jul 28, 2010 at 3:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 16, 2010 at 2:39 PM, Tom Lane wrote:
>>> I don't like the way you did that either (specifically, not the kluge
>>> in NUMERIC_DIGITS()). It would probably work better if you declared
>>> two different structs,
I wrote:
> BTW, the situation on the input side is a bit different: record_in is
> volatile because domain_in is, and I think we'd better leave that alone
> since it's not too hard to believe that a domain might have volatile
> CHECK expressions. If we had arrays of domains, anyarray_in would have
2010/7/29 Tom Lane :
> Jeff Davis writes:
>> On Wed, 2010-07-28 at 20:25 -0400, Tom Lane wrote:
>>> I can't remember offhand whether there are any volatile type output
>>> functions, but if there were we'd really need to mark array_to_string()
>>> as volatile. That would be unpleasant for perform
Oleg Bartunov writes:
> On Thu, 29 Jul 2010, Tom Lane wrote:
>> Yeah, that case works (though I think it's unnecessarily slow). The one
>> that gives the wrong answer is the equivalent form with two AND'ed @@
>> operators.
> hmm, that query works too :)
There may be some platform dependency inv
On Thu, Jul 29, 2010 at 11:09 AM, Tom Lane wrote:
> Robert Haas writes:
>> Here's a version of Jeff's fix1 patch (with a trivial change to the
>> comment) that applies to HEAD, REL9_0_STABLE, REL8_4_STABLE, and
>> REL8_3_STABLE; a slightly modified version that applies to
>> REL8_2_STABLE; and an
On Thu, 29 Jul 2010, Tom Lane wrote:
Oleg Bartunov writes:
I also wonder why did I get "right" result :) Just repeated the query:
test=# select count(*) from search_tab where (to_tsvector('german', keywords ) @@
to_tsquery('german', 'ee:* & dd:*'));
count
---
123
(1 row)
Yeah,
Jeff Davis writes:
> On Wed, 2010-07-28 at 20:25 -0400, Tom Lane wrote:
>> I can't remember offhand whether there are any volatile type output
>> functions, but if there were we'd really need to mark array_to_string()
>> as volatile. That would be unpleasant for performance though. I'd
>> rathe
New numbers on where we are with this CommitFest, as we approach the
half-way point:
72 patches were submitted
3 patches were withdrawn (deleted) by their authors
8 patches were moved to CommitFest 2010-09
--
61 patches in CommitFest 2010-07
--
3 committed to 9.0
--
58 patches for 9.1
--
1 re
27.07.2010 21:37, Tom Lane пишет:
Right. Because of the OR, it is *not* possible to conclude that
d2.basedon is always equal to 234409763, which is the implication of
putting them into an equivalence class.
In the example, we do have d1.id and d2.basedon grouped in an
equivalence class. So in
I forgot attribution in levenshtein.c file.
With best regards,
Alexander Korotkov.
fuzzystrmatch-0.5.1.tar.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
hello ...
yeah, this is fairly complicated.
greg:
can you send me how far you got?
i would be curious to see how you have attacked this issue.
i am still in the process of checking the codes.
we somehow have to find a solution for that. otherwise we are in slight trouble
here.
it seems we have
Robert Haas writes:
> Here's a version of Jeff's fix1 patch (with a trivial change to the
> comment) that applies to HEAD, REL9_0_STABLE, REL8_4_STABLE, and
> REL8_3_STABLE; a slightly modified version that applies to
> REL8_2_STABLE; and another slightly modified version that applies to
> REL8_1_
On Wed, Jul 28, 2010 at 5:22 PM, Jeff Davis wrote:
> On Wed, 2010-07-28 at 15:37 -0400, Tom Lane wrote:
>> So nevermind that distraction. I'm back to thinking that fix1 is
>> the way to go.
>
> Agreed.
>
> It's uncontroversial to have a simple guard against corrupting an
> uninitialized page, and
Robert Haas writes:
> On Thu, Jul 29, 2010 at 4:58 AM, Simon Riggs wrote:
>> Still don't understand why we would not initialize such pages. If we're
>> copying a relation we must know enough about it to init a page.
> Well, I don't see why we'd want to do that. As Jeff Davis pointed
> out, if s
Oleg Bartunov writes:
> I also wonder why did I get "right" result :) Just repeated the query:
> test=# select count(*) from search_tab where (to_tsvector('german', keywords
> ) @@ to_tsquery('german', 'ee:* & dd:*'));
> count
> ---
> 123
> (1 row)
Yeah, that case works (though I thi
Hello
I looked on patch
https://commitfest.postgresql.org/action/patch_view?id=334 .This patch
moves function xml_is_well_formed from contrib xm2 to core.
* Is the patch in context diff format?
yes
* Does it apply cleanly to the current CVS HEAD?
yes
* Does it include reasonable tests, necessa
On Thu, Jul 29, 2010 at 4:58 AM, Simon Riggs wrote:
> On Wed, 2010-07-28 at 14:22 -0700, Jeff Davis wrote:
>> On Wed, 2010-07-28 at 15:37 -0400, Tom Lane wrote:
>> > So nevermind that distraction. I'm back to thinking that fix1 is
>> > the way to go.
>>
>> Agreed.
>>
>> It's uncontroversial to ha
Hi,
We ran into a problem on 9.0beta3 with check constraints using table
inheritance in a multi-level hierarchy with multiple inheritance.
A test script is provided below and a proposed patch is attached to this
email.
Regards,
Henk Enting, Yeb Havinga
MGRID B.V.
http://www.mgrid.net
/*
F
Tom,
we're not able to work on this right now, so go ahead if you have time.
I also wonder why did I get "right" result :) Just repeated the query:
test=# select count(*) from search_tab where (to_tsvector('german', keywords ) @@
to_tsquery('german', 'ee:* & dd:*'));
count
---
123
(1
(Yes, I know I'm not on the hackers list. Most interested parties should
get this directly anyway.)
Additionally the interface exposed by the JDBC driver lets the user
write arbitrary CopyData bytes to the server, so without parsing all of
that we don't know whether they've issued CopyData(EOF
On Wed, 2010-07-28 at 14:22 -0700, Jeff Davis wrote:
> On Wed, 2010-07-28 at 15:37 -0400, Tom Lane wrote:
> > So nevermind that distraction. I'm back to thinking that fix1 is
> > the way to go.
>
> Agreed.
>
> It's uncontroversial to have a simple guard against corrupting an
> uninitialized page
48 matches
Mail list logo
