On Sun, Jul 25, 2010 at 4:32 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jul 25, 2010 at 2:37 AM, Jaime Casanova ja...@2ndquadrant.com wrote:
but i have a few questions, maybe is right what you did i only want to
understand it:
- you added this in include/storage/smgr.h, so why is
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, and
(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
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
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
/*
On Thu, Jul 29, 2010 at 4:58 AM, Simon Riggs si...@2ndquadrant.com 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
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,
Oleg Bartunov o...@sai.msu.su 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 29, 2010 at 4:58 AM, Simon Riggs si...@2ndquadrant.com 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
On Wed, Jul 28, 2010 at 5:22 PM, Jeff Davis pg...@j-davis.com 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
Robert Haas robertmh...@gmail.com 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
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
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:
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
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
Jeff Davis pg...@j-davis.com 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.
On Thu, 29 Jul 2010, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su 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
On Thu, Jul 29, 2010 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Oleg Bartunov o...@sai.msu.su 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
2010/7/29 Tom Lane t...@sss.pgh.pa.us:
Jeff Davis pg...@j-davis.com 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
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
On Wed, Jul 28, 2010 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 16, 2010 at 2:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't like the way you did that either (specifically, not the kluge
in NUMERIC_DIGITS()). It would probably work
On Thu, Jul 29, 2010 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us 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
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
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 29, 2010 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us 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?
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 robertmh...@gmail.com writes:
On Wed, Jul 28, 2010 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, you can do something like this:
typedef union numeric
{
uint16 word1;
numeric_short short;
numeric_longlong;
} numeric;
That doesn't quite work
On Thu, Jul 29, 2010 at 1:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 29, 2010 at 1:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Or we could decide that volatile domain CHECK expressions are un-sensible
and just relabel all these input functions
2010/7/29 Joshua D. Drake j...@commandprompt.com:
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
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 require a
2010/7/29 Joshua D. Drake j...@commandprompt.com:
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,
On Thu, 2010-07-29 at 19:52 +0200, Vincenzo Romano wrote:
2010/7/29 Joshua D. Drake j...@commandprompt.com:
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
On Thu, Jul 29, 2010 at 1:20 PM, Tom Lane t...@sss.pgh.pa.us 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
On Wed, Jul 28, 2010 at 1:20 AM, Mike Lewis mikelikes...@gmail.com 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
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 21, 2010 at 5:59 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 21, 2010 at 2:47 PM, Alexander Korotkov
aekorot...@gmail.com wrote:
On Wed, Jul 21, 2010 at 10:25 PM, Robert Haas robertmh...@gmail.com wrote:
*scratches head* Aren't you just moving the same call to a
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 29, 2010 at 1:20 PM, Tom Lane t...@sss.pgh.pa.us 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*
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
On Thu, Jul 29, 2010 at 4:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jul 29, 2010 at 1:20 PM, Tom Lane t...@sss.pgh.pa.us 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
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, it
On Wed, Jul 28, 2010 at 11:51 AM, Boxuan Zhai bxzhai2...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Thu, Jul 29, 2010 at 5:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
2010/7/29 Josh Berkus j...@agliodbs.com:
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
Robert Haas robertmh...@gmail.com 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
Dave Page dp...@pgadmin.org 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
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
On Thu, Jul 29, 2010 at 5:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
49 matches
Mail list logo
