Erik Rijkers e...@xs4all.nl writes:
I might be mistaken but it looks like a doc/src/sgml/ref/alter_extension.sgml
is missing?
Mmm, it seems that git was agreeing with you, so here's it:
git ls-files doc/src/sgml/ref/alter_extension.sgml
Alvaro Herrera alvhe...@commandprompt.com writes:
function link
linkend=functions-extensionpg_extension_flag_dump/link
[...]
So presumably this shouldn't be documented because it cannot be called
anyway?
It can be called but only from an extension's script.
To be honest I don't
On Dec18, 2010, at 17:59 , Tomas Vondra wrote:
It seems to me you're missing one very important thing - this was not
meant as a new default way to do estimates. It was meant as an option
when the user (DBA, developer, ...) realizes the current solution gives
really bad estimates (due to
for column bid
CONTEXT: COPY csv_tellers_bad, line 10: 10
postgres=#
* Only superusers can change table-level file_fdw options. Normal
user can't change the options even if the user was the owner of the
table. This is for security reason.
Regards,
--
Shigeru Hanada
file_fdw-20101221
On Mon, Dec 20, 2010 at 9:29 PM, Florian Pflug f...@phlo.org wrote:
I tried to pick up Robert's idea of quantifying Implicativeness -
i.e., finding a number between 0 and 1 that describes how close the
(A,B) are to representing a function A - B.
Actually Heikki's idea...
Observe that
On Mon, Dec 20, 2010 at 3:14 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 20, 2010 at 3:11 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 20, 2010 at 2:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I like that better actually ... one less
2010/12/21 Tomáš Mudruňka to...@mudrunka.cz:
Is there possibility of having internal base converting function in PgSQL?
There are already functions for converting between decimal and hexadecimal
notations i think pgsql can be able to convert between number with radixes
from 1 to 36 (actually
On Sun, Dec 19, 2010 at 1:10 PM, Jim Nasby j...@nasby.net wrote:
On Dec 19, 2010, at 1:10 AM, flyusa2010 fly wrote:
Does postgres make an effort to create a file with physically continuous
blocks?
AFAIK all files are expanded as needed. I don't think there's any flags you
can pass to the
Dne 21. prosince 2010 12:48 Robert Haas robertmh...@gmail.com napsal(a):
2010/12/21 Tomáš Mudruňka to...@mudrunka.cz:
Is there possibility of having internal base converting function in PgSQL?
There are already functions for converting between decimal and hexadecimal
notations i think pgsql
On Mon, Dec 20, 2010 at 9:29 PM, Florian Pflug f...@phlo.org wrote:
You might use that to decide if either A-B or B-a looks function-like
enough to use the uniform bayesian approach. Or you might even go
further,
and decide *with* bayesian formula to use - the paper you cited always
averages
On Tue, Dec 21, 2010 at 20:14, Shigeru HANADA han...@metrosystems.co.jp wrote:
Attached is the revised version of file_fdw patch. This patch is
based on Itagaki-san's copy_export-20101220.diff patch.
#1. Don't you have per-tuple memory leak? I added GetCopyExecutorState()
because the caller
On Mon, Dec 20, 2010 at 6:42 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Sun, Dec 19, 2010 at 12:45, Robert Haas robertmh...@gmail.com wrote:
I'm not questioning any of that. But I'd like the resulting code to
be as maintainable as we can make it.
I added comments and moved
There is a bug in ts_rank_cd. It does not correctly give rank when the
query lexeme is the first one in the tsvector.
Example:
select ts_rank_cd(to_tsvector('english', 'abc sdd'),
plainto_tsquery('english', 'abc'));
ts_rank_cd
0
select
MY PREV EMAIL HAD A PROBLEM. Please reply to this one
==
There is a bug in ts_rank_cd. It does not correctly give rank when the
query lexeme is the first one in the tsvector.
Example:
select ts_rank_cd(to_tsvector('english', 'abc sdd'),
On Dec21, 2010, at 12:48 , Robert Haas wrote:
2010/12/21 Tomáš Mudruňka to...@mudrunka.cz:
Is there possibility of having internal base converting function in PgSQL?
There are already functions for converting between decimal and hexadecimal
notations i think pgsql can be able to convert
On Dec21, 2010, at 11:37 , t...@fuzzy.cz wrote:
I doubt there is a way to this decision with just dist(A), dist(B) and
dist(A,B) values. Well, we could go with a rule
if [dist(A) == dist(A,B)] the [A = B]
but that's very fragile. Think about estimates (we're not going to work
with exact
On Dec21, 2010, at 11:37 , t...@fuzzy.cz wrote:
I doubt there is a way to this decision with just dist(A), dist(B) and
dist(A,B) values. Well, we could go with a rule
if [dist(A) == dist(A,B)] the [A = B]
but that's very fragile. Think about estimates (we're not going to work
with exact
On Dec21, 2010, at 15:51 , t...@fuzzy.cz wrote:
This is the reason why they choose to always combine the values (with
varying weights).
There are no varying weights involved there. What they do is to express
P(A=x,B=y) once as
...
P(A=x,B=y) ~= P(B=y|A=x)*P(A=x)/2 +
On Tue, December 21, 2010 09:57, Dimitri Fontaine wrote:
Erik Rijkers e...@xs4all.nl writes:
I might be mistaken but it looks like a
doc/src/sgml/ref/alter_extension.sgml is missing?
Mmm, it seems that git was agreeing with you, so here's it:
git ls-files
On Dec21, 2010, at 13:25 , t...@fuzzy.cz wrote:
And there's one additional - IMHO very important - requirement. The whole
thing should easily extend to more than two columns. This IF (F(A,B)
F(B,A)) THEN ... probably is not a good solution regarding this.
For example given 3 columns A,B,C,
On Wed, Dec 15, 2010 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
- Writeable CTEs - I think we need Tom to pick this one up.
- Fix snapshot taking inconsistencies - Ready for committer. Can any
committer pick this up?
Will take a look at these two also.
Tom, what is your time frame on
Would be great if owner can be inherited from parent object (owner table ==
schema owner == database owner).
CREATE statement could add OWNER TO PARENT to cover this feature.
Michel
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
- Writeable CTEs - I think we need Tom to pick this one up.
- Fix snapshot taking inconsistencies - Ready for committer. Can any
committer pick this up?
Will take a look at these
Erik Rijkers e...@xs4all.nl writes:
http://pgsql.tapoueh.org/extensions/doc/html/sql-alterextension.html
[...]
Two changes to sql-alterextension.sgml:
Fixed and uploaded on the URL above, will be in the next patch revision,
thanks!
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr
gsdfg gdfg mx.mo...@gmail.com writes:
Would be great if owner can be inherited from parent object (owner table ==
schema owner == database owner).
CREATE statement could add OWNER TO PARENT to cover this feature.
What it would be is a great security hole --- exactly analogous to
allowing Unix
On 12/21/2010 07:04 AM, gsdfg gdfg wrote:
Would be great if owner can be inherited from parent object (owner
table == schema owner == database owner).
CREATE statement could add OWNER TO PARENT to cover this feature.
That syntax would violate POLA in the case of inherited tables (OWNER TO
On Dec21, 2010, at 15:51 , t...@fuzzy.cz wrote:
This is the reason why they choose to always combine the values (with
varying weights).
There are no varying weights involved there. What they do is to express
P(A=x,B=y) once as
...
P(A=x,B=y) ~= P(B=y|A=x)*P(A=x)/2 + P(A=x|B=y)*P(B=y)/2
HI,
for the histograms for cost based optimization, is there a rule of thumb on how
often to rebuild them? They are obviously not being continuously updated...what
is the state of the art in this area, do all the other databases also end up
with stale statistics every now and then and have to
amit sehas cu...@yahoo.com wrote:
for the histograms for cost based optimization, is there a rule of
thumb on how often to rebuild them?
In recent major versions, autovacuum should normally keep you in
good shape. The exception is when you make major changes to the
contents of a table (such
Dne 21.12.2010 16:54, Florian Pflug napsal(a):
Hmmm, maybe we could give this possibility (to identify two separate
groups of columns) to the user. So instead of 'buid stats for (A,B,C)' the
user would say 'build stats for (A,B) and (C)' - this actually represents
apriori knowledge of
On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Mon, Dec 20, 2010 at 03:08:02PM -0500, Robert Haas wrote:
The attached patch appears to work correctly on MacOS X. I did check,
BTW: getppid() in the attached process returns gdb's pid. Poor!
This appears to
Hi Hackers.
I have a feeling that GIN is cheating on the visibillity checks:
test=# set enable_seqscan = off;
SET
Time: 0.129 ms
test=# select count(id) from fts_test where fts @@ to_tsquery('core');
count
158827
(1 row)
Time: 95.530 ms
test=# explain select count(id) from fts_test
On Wed, 2010-12-15 at 22:25 +0900, Shigeru HANADA wrote:
Attached are revised version of SQL/MED core functionality patches.
Looks very interesting new feature, well done.
Can I ask some questions about how this will work?
No particular order, just numbered for reference.
1. The docs don't
On Tue, Dec 21, 2010 at 1:45 PM, Eric Ridge eeb...@gmail.com wrote:
On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout
klep...@svana.org wrote:
On Mon, Dec 20, 2010 at 03:08:02PM -0500, Robert Haas wrote:
The attached patch appears to work correctly on MacOS X. I did check,
BTW:
On Tue, Dec 21, 2010 at 2:33 PM, Robert Haas robertmh...@gmail.com wrote:
The point of the patch was to improve cases where attaching gdb
*didn't* work well. Any cases where it was already working for you
aren't going to be made worse by this.
Okay, great. Thanks for the clarification.
eric
On 21.12.2010 21:25, Jesper Krogh wrote:
The first query should have the cost of the GIN-search +
visibillity-test of 158K tuples,
the latter should have the cost of visibillity-testing 168K tuples. If
we set the cost
of actually searching GIN to 0 then the gin-search - visibillity costs:
Excerpts from Robert Haas's message of mar dic 21 08:40:49 -0300 2010:
Well, non-developers don't tend to attach gdb very often. Alvaro
mentioned a problem installation upthread, thus the question.
Hearing no cries of please-oh-please-backpatch-this, I've committed
it just to master.
Thx for you answers :-)
Well... i know that i can write my own plugin and i am familiar with C so
this is not the problem, but i think that such feature should be
implemented directly in PgSQL because there are already functions for
converting to/from base 16 so why don't make this more flexible
On Tuesday 21 December 2010 20:25:16 Jesper Krogh wrote:
What have I missed in the logic?
A reproducible testcase ;-)
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello
Dne 21. prosince 2010 21:11 Tomáš Mudruňka to...@mudrunka.cz napsal(a):
Thx for you answers :-)
Well... i know that i can write my own plugin and i am familiar with C so
this is not the problem, but i think that such feature should be
implemented directly in PgSQL because there are
On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
On 2010-11-12 8:25 PM +0200, I wrote:
I'm going to take some time off this weekend to get a patch with this
behaviour to the next commitfest.
.. and a wild patch appears.
This is almost exactly the patch from 2010-02 without
Hi,
Found a couple of small typos in the comments of nodeWindowAgg.c when
they refer to functions in nodeAgg.c. The pluralities of the function
names (initialize_aggregates and advance_aggregates) are wrong. The
reference to finalize_aggregate is correct though.
diff --git
On Tue, Dec 21, 2010 at 11:14:31PM +0200, Peter Eisentraut wrote:
On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
On 2010-11-12 8:25 PM +0200, I wrote:
I'm going to take some time off this weekend to get a patch with this
behaviour to the next commitfest.
.. and a wild patch
Hello, Pavel.
You wrote:
PS Hello
PS Dne 21. prosince 2010 21:11 Tomáš Mudruňka to...@mudrunka.cz napsal(a):
Thx for you answers :-)
Well... i know that i can write my own plugin and i am familiar with C so
this is not the problem, but i think that such feature should be
implemented
On Tue, Dec 21, 2010 at 11:28:17PM +0200, Pavel Golub wrote:
Hello, Pavel.
You wrote:
PS Hello
PS Dne 21. prosince 2010 21:11 Tom Mudru??ka to...@mudrunka.cz
napsal(a):
Thx for you answers :-)
Well... i know that i can write my own plugin and i am familiar with C so
this is
On 12/21/2010 04:28 PM, Pavel Golub wrote:
PS * It isn't a typical and often request,
PS * There are not hard breaks for custom implementation,
PS * You can use plperu or plpython based solutions,
PS * It's not part of ANSI SQL
But MySQL has such function. What's wrong with us? ;)
Our
Hello.
Guys, guys! It was only a joke! :)
Please accept my appologies.
Anyway I find such function usefull even though I still hadn't
situation when it might be needed.
You wrote:
AD On 12/21/2010 04:28 PM, Pavel Golub wrote:
PS * It isn't a typical and often request,
PS * There are not
On Tue, Dec 21, 2010 at 4:57 PM, Pavel Golub pa...@microolap.com wrote:
Anyway I find such function usefull even though I still hadn't
situation when it might be needed.
Yeah, I agree. I'm not sure we should add it to core, but it's
certainly just as useful as many things we have in contrib.
On Mon, 29 Nov 2010 10:29:17 -0300
Alvaro Herrera alvhe...@commandprompt.com wrote:
Excerpts from Quan Zongliang's message of sáb nov 27 06:03:12 -0300 2010:
Hi, all
I created a pg_ctl patch to fix:
* BUG #5103: pg_ctl -w (re)start fails with custom unix_socket_directory
Allow pg_ctl
On Tue, Dec 21, 2010 at 4:17 PM, Andreas Karlsson andr...@proxel.se wrote:
Found a couple of small typos in the comments of nodeWindowAgg.c when
they refer to functions in nodeAgg.c. The pluralities of the function
names (initialize_aggregates and advance_aggregates) are wrong. The
reference
On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch n...@leadboat.com wrote:
When the caller knows the smaller string length, memcmp and strncmp are
functionally equivalent. Since memcmp need not watch each byte for a NULL
terminator, it often compares a CPU word at a time for better performance.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 21.12.2010 21:25, Jesper Krogh wrote:
Or is a Bitmap Heap Scan simply 3 times faster than a Seq-scan for
visibillity-testing?
It certainly shouldn't be.
What have I missed in the logic?
Perhaps you have a lot of empty space
Merlin Moncure mmonc...@gmail.com wrote:
*) what's a good way to stress the clog severely? I'd like to pick
a degenerate case to get a better idea of the way things stand
without them.
The worst I can think of is a large database with a 90/10 mix of
reads to writes -- all short
On 22/12/10 11:42, Merlin Moncure wrote:
Attached is an incomplete patch disabling hint bits based on compile
switch. It's not complete, for example it's not reconciling some
assumptions in heapam.c that hint bits have been set in various
routines. However, it mostly passes regression and I
On 22/12/10 13:05, Mark Kirkwood wrote:
On 22/12/10 11:42, Merlin Moncure wrote:
Attached is an incomplete patch disabling hint bits based on compile
switch. It's not complete, for example it's not reconciling some
assumptions in heapam.c that hint bits have been set in various
routines.
On Tue, Dec 21, 2010 at 7:06 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On 22/12/10 13:05, Mark Kirkwood wrote:
On 22/12/10 11:42, Merlin Moncure wrote:
Attached is an incomplete patch disabling hint bits based on compile
switch. It's not complete, for example it's not
On Tue, Dec 21, 2010 at 7:20 PM, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Dec 21, 2010 at 7:06 PM, Mark Kirkwood
mark.kirkw...@catalyst.net.nz wrote:
On 22/12/10 13:05, Mark Kirkwood wrote:
On 22/12/10 11:42, Merlin Moncure wrote:
Attached is an incomplete patch disabling hint bits
Merlin Moncure mmonc...@gmail.com writes:
Attached is an incomplete patch disabling hint bits based on compile
switch. ...
So far, at least doing pgbench runs and another test designed to
exercise clog lookups, the performance loss of always doing full
lookup hasn't materialized.
The
On Tue, Dec 21, 2010 at 7:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
Attached is an incomplete patch disabling hint bits based on compile
switch. ...
So far, at least doing pgbench runs and another test designed to
exercise clog lookups, the
On Sat, Dec 18, 2010 at 1:00 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Dec 17, 2010 at 10:27 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I think the attached might be a little tidier. Thoughts?
I'm not really thrilled at the idea of calling
Excerpts from Quan Zongliang's message of mar dic 21 18:36:11 -0300 2010:
On Mon, 29 Nov 2010 10:29:17 -0300
Alvaro Herrera alvhe...@commandprompt.com wrote:
I think the way this should work is that you call postmaster with a new
switch and it prints out its configuration, after reading
On Tue, Dec 21, 2010 at 6:24 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch n...@leadboat.com wrote:
When the caller knows the smaller string length, memcmp and strncmp are
functionally equivalent. Since memcmp need not watch each byte for a
NULL
On Tue, Dec 21, 2010 at 4:49 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Dec 19, 2010 at 1:10 PM, Jim Nasby j...@nasby.net wrote:
On Dec 19, 2010, at 1:10 AM, flyusa2010 fly wrote:
Does postgres make an effort to create a file with physically continuous
blocks?
AFAIK all files are
On Tue, Dec 21, 2010 at 8:29 PM, Gurjeet Singh singh.gurj...@gmail.com wrote:
On Tue, Dec 21, 2010 at 6:24 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch n...@leadboat.com wrote:
When the caller knows the smaller string length, memcmp and strncmp are
On Tue, Dec 21, 2010 at 9:01 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 21, 2010 at 8:29 PM, Gurjeet Singh singh.gurj...@gmail.com
wrote:
On Tue, Dec 21, 2010 at 6:24 PM, Robert Haas robertmh...@gmail.com
wrote:
On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch n...@leadboat.com
On 22/12/10 13:56, Merlin Moncure wrote:
On Tue, Dec 21, 2010 at 7:45 PM, Tom Lanet...@sss.pgh.pa.us wrote:
@Mark: apparently the cvs server is behind git and there are some
recent changes to heapam.c that need more attention. I need to get
git going on my box, but try changing this:
Fujii Masao masao.fu...@gmail.com writes:
How about doing target != ALL test at the head for the most common case
(target == ALL)?
That's an idea, but the test you propose implements it incorrectly.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Tue, Dec 21, 2010 at 6:24 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch n...@leadboat.com wrote:
When the caller knows the smaller string length, memcmp and strncmp are
functionally equivalent. Since memcmp need not watch each byte for a NULL
Robert Haas robertmh...@gmail.com writes:
If it's done properly, I don't see how this would be a risk.
I'm fairly uncomfortable about the broad swath and low return of this
patch. Noah is assuming that none of these places are relying on
strncmp to stop short upon finding a null, and I don't
On Tue, Dec 21, 2010 at 10:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
If it's done properly, I don't see how this would be a risk.
I'm fairly uncomfortable about the broad swath and low return of this
patch. Noah is assuming that none of these places
On Tue, Dec 21, 2010 at 11:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
- Writeable CTEs - I think we need Tom to pick this one up.
- Fix snapshot taking inconsistencies - Ready for
Sushant Sinha sushant...@gmail.com writes:
There is a bug in ts_rank_cd. It does not correctly give rank when the
query lexeme is the first one in the tsvector.
Hmm ... I cannot reproduce the behavior you're complaining of.
You say
select ts_rank_cd(to_tsvector('english', 'abc sdd'),
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 21, 2010 at 10:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm fairly uncomfortable about the broad swath and low return of this
patch. Noah is assuming that none of these places are relying on
strncmp to stop short upon finding a null, and
On Mon, Dec 20, 2010 at 00:39, Alex Hunsaker bada...@gmail.com wrote:
In further review over caffeine this morning I noticed there are a few
places I missed: plperl_build_tuple_result(), plperl_modify_tuple()
and Util.XS.
And here is v3, fixes the above and also makes sure to properly
On 2010-12-21 21:28, Andres Freund wrote:
On Tuesday 21 December 2010 20:25:16 Jesper Krogh wrote:
What have I missed in the logic?
A reproducible testcase ;-)
Yes, I did a complete dump/restore of the dataset and the numbers
looked like expected. So table bloat seems to be the
On Wed, Dec 22, 2010 at 12:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
How about doing target != ALL test at the head for the most common case
(target == ALL)?
That's an idea, but the test you propose implements it incorrectly.
Thanks! I revised the
On 22.12.2010 03:45, Rob Wultsch wrote:
On Tue, Dec 21, 2010 at 4:49 AM, Robert Haasrobertmh...@gmail.com wrote:
On Sun, Dec 19, 2010 at 1:10 PM, Jim Nasbyj...@nasby.net wrote:
On Dec 19, 2010, at 1:10 AM, flyusa2010 fly wrote:
Does postgres make an effort to create a file with physically
On 22.12.2010 02:56, Merlin Moncure wrote:
On Tue, Dec 21, 2010 at 7:45 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Merlin Moncuremmonc...@gmail.com writes:
Attached is an incomplete patch disabling hint bits based on compile
switch. ...
So far, at least doing pgbench runs and another test
On Wed, Dec 22, 2010 at 12:15 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 22.12.2010 03:45, Rob Wultsch wrote:
On Tue, Dec 21, 2010 at 4:49 AM, Robert Haasrobertmh...@gmail.com
wrote:
On Sun, Dec 19, 2010 at 1:10 PM, Jim Nasbyj...@nasby.net wrote:
On Dec 19,
On 22.12.2010 09:25, Rob Wultsch wrote:
On Wed, Dec 22, 2010 at 12:15 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, innodb_autoextend_increment seems more like what we're discussing here
80 matches
Mail list logo
