On 26/12/10 20:57, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> How about a format like this then:
>
>> # Comment
>> Section: Class 2F - SQL Routine Exception
>> macro_name sqlstate plpgsqlname is_error
>
>> That is: # and blank lines are comments, lines starting with "Section:"
On 26/12/10 20:33, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> I then tried to do the same for plerrcodes.h, but found discrepancies.
>
> You shouldn't assume that errcodes.h necessarily includes all the info
> needed to create the other two files.
>
> The way I'd envision this
On 26/12/10 18:17, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Dec 26, 2010 at 8:03 AM, Jan Urbański wrote:
>>> See
>>> https://github.com/wulczer/postgres/commit/44fc42b7708f23483156e4e0e1e321e68b2a7e2d#diff-0
>>> for something that maybe coul
On 26/12/10 05:55, Robert Haas wrote:
> On Sat, Dec 25, 2010 at 3:39 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Add foreign data wrapper error code values for SQL/MED.
>>> Extracted from a much larger patch by Shigeru Hanada.
>>
>> This patch is quite incomplete. Any patch that adds to errco
Here's a patch implementing custom Python exceptions for SPI errors
mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the explicit-subxacts patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/cust
Here's a patch implementing explicitly starting subtransactions mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the spi-in-subxacts patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/explicit-s
Here's a patch implementing custom parsers for data types mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/custom-parsers
Here's a patch implementing table functions mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/table-functions.
This allow
Here's a patch implementing traceback support for PL/Python mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/tracebacks.
Here's a patch implementing properly invalidating functions that have
composite type arguments after the type changes, as mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for thi
Here's a patch implementing a executing SPI in an subtransaction
mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/spi-in-
On 23/12/10 14:41, Jan Urbański wrote:
> Here's a patch implementing a validator functoin mentioned in
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
> an incremental patch on top of the plpython-refactor patch sent eariler.
>
> Git branc
Here's a patch implementing a validator functoin mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
https://github.com/wulczer/postgres/tree/validator.
Cheers,
Jan
On 23/12/10 12:16, Marti Raudsepp wrote:
> On Thu, Dec 23, 2010 at 04:08, Jan Urbański wrote:
>> * providing custom exceptions for SPI errors, so you can catch only
>> UniqueViolations and not have to muck around with SQLCODE
>
> py-postgresql already has a mapping from
On 08/12/10 22:41, Peter Eisentraut wrote:
> On tis, 2010-12-07 at 23:56 +0100, Jan Urbański wrote:
>> Peter suggested having a mail/patch per feature and the way I intend
>> to do that is instead of having a dozen branches, have one and after
>> I'm done rebase i
On 18/12/10 18:56, Jan Urbański wrote:
> I'm not a Python 3 expert, but I nicked some code from the Internet and
> came up with this patch (passes regression tests on both Python 2 and 3).
I tried to be too cute with the regression test, it fails with Python
2.3.7 (the latest
Hi,
there seems to be a problem in the way we add exceptions to the plpy
module in PL/Python compiled with Python 3k.
Try this: DO $$ plpy.SPIError $$ language plpython3u;
I'm not a Python 3 expert, but I nicked some code from the Internet and
came up with this patch (passes regression tests on
On 15/12/10 16:25, Dmitriy Igrishin wrote:
> 2010/12/15 Jan Urbański
>> So how about just adding a text column to pg_type and a IDENTIFIER
>> keywork to CREATE TYPE. It's not guaranteed to be unique, but isn't it
>> pushing the argument to the extreme? Someone can
On 15/12/10 16:11, Tom Lane wrote:
> Robert Haas writes:
>> I was asking what would satisfy you as regards a reliable way to
>> identify a type, not what you think we should do about this particular
>> proposal.
>
> Okay: a preassigned OID is safe. I haven't seen any other safe
> proposals. Rel
On 15/12/10 15:38, Tom Lane wrote:
> Jan =?utf-8?B?VXJiYcWEc2tp?= writes:
>> OK, here's another master plan:
>
>> 1) hstore_plplython, when loaded, looks for a type called "hstore". If
> you created a "hstore" type that does not come from hstore.so, and you
> still load hstore_plpython, you deser
On Wed, Dec 15, 2010 at 12:19:53AM +0100, Jan Urbański wrote:
> Problem: what to do it hstore_plpython gets loaded, but hstore is not
> yet loaded. hstore_plpython will want to DirectFunctionCall(hstore_in),
> so loading hstore_plpython without loading hstore will result in an
> e
On 14/12/10 17:52, Tom Lane wrote:
> Peter Eisentraut writes:
>> On mån, 2010-12-13 at 08:50 +0100, Jan Urbański wrote:
>>> It would be cool to be able to transparently use hstores as Python
>>> dictionaries and vice versa. It would be easy enough with hstore as a
>
On 14/12/10 18:05, David E. Wheeler wrote:
> On Dec 13, 2010, at 11:37 PM, Jan Urbański wrote:
>
>> A function said to be returning a hstore could return a dictionary and if it
>> would have only string keys/values, it would be changed into a hstore (and
>> if not,
> Robert Haas writes:
> > On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane wrote:
> It seems like what we need at this point is a detailed, non-arm-waving
> design for what Jan would do in pl/python if hstore were in core. Then
> we can look at it and see exactly what we'd lose from keeping hstore out
It would be cool to be able to transparently use hstores as Python
dictionaries and vice versa. It would be easy enough with hstore as a
core type, but with hstore as an addon it's not that easy.
There was talk about including hstore in core, is there still chance for
that to happen in 9.1? I'd li
On 08/12/10 21:18, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> I'm pleasantly surprised that the SA code as it stands today, setting
>> the equlibrium factor to 8 and temperature reduction factor to 0.4, the
>> query takes 1799.662 ms in total.
>
> Cool.
>
>> With the default v
On 08/12/10 19:02, Jan Urbański wrote:
> On 08/12/10 18:45, Tom Lane wrote:
>> The real fix in my mind is to replace GEQO search with something
>> smarter. I wonder what happened to the SA patch that was reported
>> on at PGCon.
>
> I got distracted with other things
On 08/12/10 18:45, Tom Lane wrote:
> The real fix in my mind is to replace GEQO search with something
> smarter. I wonder what happened to the SA patch that was reported
> on at PGCon.
I got distracted with other things :( I'll try to plan the two queries
with SA and see what the results are. If
On 07/12/10 23:00, Andrew Dunstan wrote:
> On 12/07/2010 04:50 PM, Peter Eisentraut wrote:
>>
>>> The code is on https://github.com/wulczer/postgres, in the plpython
>>> branch. I'll be rebasing it regularly, so don't be surprised by commit
>>> hashes changing.
>> I think rebasing published reposit
On 07/12/10 21:33, Andres Freund wrote:
> On Tuesday 07 December 2010 20:17:57 Jan Urbański wrote:
>> * execute SPI calls in a subtransaction, report errors back to Python
>> as exceptions that can be caught etc.
> Youre doing that unconditionally? I think the performance i
Hi,
no, no patch(es) yet. I'm going through plpython.c trying as best I can
to improve things there. I'll have a patch (or patches) ready for the
January commitfest, but I thought I'd open up a discussion already to
spare me having to redo features because the way I attacked the problem
is a dead
On 28/11/10 05:23, Andrew Dunstan wrote:
>
>
> On 11/27/2010 10:28 PM, Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>>> I noticed that PL/Python uses a simple wrapper around malloc that does
>>> ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
>>> normally do
I noticed that PL/Python uses a simple wrapper around malloc that does
ereport(FATAL) if malloc returns NULL. I find it a bit harsh, don't we
normally do ERROR if we run out of memory?
And while looking at how PL/Perl does these things I find that one
failed malloc (in compile_plperl_function) thr
On 24/10/10 00:32, Jan Urbański wrote:
> On 21/10/10 20:48, Alvaro Herrera wrote:
>> ... and presumably somebody can fix the real bug that Jean-Baptiste hit,
>> too.
>
> AFAICS the error comes from PLy_function_handler disconnecting from SPI
> after calling into the Py
On 04/11/10 20:43, Hannu Krosing wrote:
> On Thu, 2010-11-04 at 11:07 -0600, Alex Hunsaker wrote:
>> On Thu, Nov 4, 2010 at 03:54, Hannu Krosing wrote:
> try:
> plpy.execute("insert into foo values(1)")
> except plpy.UniqueViolation, e:
> plpy.notice("Ooops, you got yoursel
On 04/11/10 14:09, Robert Haas wrote:
> On Thu, Nov 4, 2010 at 6:05 AM, Itagaki Takahiro
> wrote:
>> 2010/11/4 KaiGai Kohei :
>>> The attached patch is a contrib module to inject a few seconds
>>> delay on authentication failed. It is also a proof of the concept
>>> using the new ClientAuthenticat
On 03/11/10 20:57, Alex Hunsaker wrote:
> On Wed, Nov 3, 2010 at 10:28, Tom Lane wrote:
>> OK, applied.
>
> Thanks!
>
>> I notice that plpython is also using the trigger relation's OID, but I
>> don't know that language well enough to tell whether it really needs to.
>
> This thread was started
On 25/10/10 03:59, Andrew Dunstan wrote:
>
>
> On 10/24/2010 09:34 PM, Tom Lane wrote:
>>
>>> For both trigger and non-trigger functions, we compile this ahead of the
>>> user-set function code:
>>> our $_TD; local $_TD=shift;
>>> Non-trigger functions get passed "undef" to correspond to thi
I see that plperl uses a triple of (function oid, is_trigger flag, user
id) as a hash key for caching compiled functions. OTOH pltcl and plpgsql
both use (oid, trigger relation oid, user id). Is there any reason why
just using a bool as plperl does would be wrong?
I'm trying to write a validator f
On 24/10/10 14:44, Sushant Sinha wrote:
> I am using gin index on a tsvector and doing basic search. I see the
> row-estimate of the planner to be horribly wrong. It is returning
> row-estimate as 4843 for all queries whether it matches zero rows, a
> medium number of rows (88,000) or a large numbe
On 24/10/10 14:44, Sushant Sinha wrote:
> I am using gin index on a tsvector and doing basic search. I see the
> row-estimate of the planner to be horribly wrong. It is returning
> row-estimate as 4843 for all queries whether it matches zero rows, a
> medium number of rows (88,000) or a large numbe
On 21/10/10 20:48, Alvaro Herrera wrote:
> Excerpts from Alvaro Herrera's message of jue oct 21 15:32:53 -0300 2010:
>> Excerpts from Jean-Baptiste Quenot's message of jue oct 21 09:20:16 -0300
>> 2010:
>>
>>> I get this error when calling the function:
>>>
>>> test=# select foobar();
>>> ERROR:
OK, here's a review, as much as I was able to do it without
understanding deeply how GIN works.
The patch is context, applies cleanly to HEAD, compiles without warnings
and passes regression tests.
Using the script from
http://archives.postgresql.org/pgsql-performance/2009-10/msg00393.php I
On 24/07/10 15:20, Adriano Lange wrote:
Hi,
Hi!
I'd like to release the last version of my experimental join order
algorithm (TwoPO - Two Phase Optimization [1]):
http://git.c3sl.ufpr.br/gitweb?p=lbd/ljqo.git;a=summary
This algorithm is not production-ready, but an experimental set of
idea
On 26/07/10 12:58, Oleg Bartunov wrote:
Jan,
On Sun, 25 Jul 2010, Jan Urbaski wrote:
On 02/07/10 14:33, Teodor Sigaev wrote:
Patch implements much more accuracy estimation of cost for GIN index
scan than generic cost estimation function.
I was able to reproduce his issue, that is: select i
On 02/07/10 14:33, Teodor Sigaev wrote:
> Patch implements much more accuracy estimation of cost for GIN index
> scan than generic cost estimation function.
Hi,
I'm reviewing this patch, and to begin with it I tried to reproduce the
problem that originally came up on -performance in
http://archiv
On 23/07/10 20:55, Pavel Stehule wrote:
> Hello
>
> 2010/7/23 Jan Urbański :
>> On 21/07/10 14:43, Pavel Stehule wrote:
>>> Hello
>>>
>>> I am sending a actualised patch.
OK, thanks. This time the only thing I'm not happy about is the error
mes
On 21/07/10 14:43, Pavel Stehule wrote:
> Hello
>
> I am sending a actualised patch.
Hi, thanks!
> I understand to your criticism about line numbering. I have to
> agree. With line numbering the patch is longer. I have a one
> significant reason for it.
> CREATE OR REPLACE FUNCTION public
Hi,
here's a review of the \sf and \ef [num] patch from
http://archives.postgresql.org/message-id/162867791003290927y3ca44051p80e697bc6b19d...@mail.gmail.com
== Formatting ==
The patch has some small tabs/spaces and whitespace issues and it
applies with some offsets, I ran pgindent and rebase
On 07/07/10 17:19, Peter Froehlich wrote:
On Wed, Jul 7, 2010 at 8:49 AM, Peter Eisentraut wrote:
If you want to hack PL/Python, which is a Python interpreter embedded
into the PostgreSQL server, then this is the right place. (Yes, it's
mixed with all the rest.)
If you want to hack a Python c
Hi,
per $SUBJECT.
Cheers,
Jan
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index 9de4189..ebdf812 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -1870,6 +1870,7 @@ help(void)
printf(_("(can be used mult
On 31/05/10 00:07, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> I committed the attached revised version of the patch. Revisions are
> mostly minor but I did make two substantive changes:
>
> * The patch changed the target number of mcelems from 10 *
> statistics_target to just s
On 30/05/10 09:08, Jesper Krogh wrote:
> On 2010-05-29 15:56, Jan Urbański wrote:
>> On 29/05/10 12:34, Jesper Krogh wrote:
>>> I can "fairly easy" try out patches or do other kind of testing.
>>>
>> I'll try to come up with a patch for y
> Jesper Krogh writes:
> > On 2010-05-29 15:56, Jan Urbański wrote:
> > > AFAIK statistics for everything other than tsvectors are built based
> > > on the values of whole rows.
>
> > Wouldn't it make sense to treat array types like the tsvectors?
>
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
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
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
>
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 of MCV entries or perhaps a bit more.
On 28/05/10 04:47, Tom Lane wrote:
> I re-scanned that paper and realized that there is indeed something
> wrong with the way we are doing it. The paper says (last sentence in
> the definition of the algorithm, section 4.2):
>
> When a user requests a list of items with threshold s, we outp
On 28/05/10 04:47, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> On 19/05/10 21:01, Jesper Krogh wrote:
>>> In practice, just cranking the statistics estimate up high enough seems
>>> to solve the problem, but doesn't
>>> there seem to be something wrong in how the statistics are c
On 19/05/10 21:01, Jesper Krogh wrote:
> The document base is arount 350.000 documents and
> I have set the statistics target on the tsvector column
> to 1000 since the 100 seems way of.
So for tsvectors the statistics target means more or less "at any time
track at most 10 * lexemes simultaneous
On 24/03/10 21:06, Markus Wanner wrote:
Steve,
Steve Singer wrote:
$ git clone http://git.postgres-r.org/dtester
Initialized empty Git repository in
/local/home/ssinger/src/dtester/dtester/.git/
fatal: http://git.postgres-r.org/dtester/info/refs download error -
The requested URL returned error
Arie Bikker wrote:
> Hi all,
>
> I've combined the review suggestions of Jan Urbański, Scott Bailey, and
> others.
> This was a lot harder, then I had foreseen; and I took my time to do it
> the right way (hope you agree!).
Hi,
I see the patch has been marked as "Re
Hi,
here's a review of the patch:
It applies with offsets, but worked fine for me. It works as advertised,
and I believe it is a solid step forward from the current situation.
As far as the coding goes, the PG_TRY/CATCH in xml_xmlpathobjtoxmltype
seems unnecessary in the XPATH_BOOLEAN branch, as
Markus Wanner wrote:
>> I do want to expand the tests quite a bit -- do I work them all into
>> this same file, or how would I proceed? I think I'll need about 20
>> more tests, but I don't want to get in the way of your work on the
>> framework which runs them.
>
> Well, first of all, another pi
Andres Freund wrote:
> On Wednesday 23 December 2009 02:23:55 Jan Urbański wrote:
>> Lastly, I'm lacking good testcases
> If you want to see some queries which are rather hard to plan with random
> search you can look at
> http://archives.postgresql.org/message-
>
Hi,
I've been playing with using a Simulated Annealing-type algorithm for
determinig join ordering for relations. To get into context see
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00098.php
(there's also a TODO in the wiki). There's a nice paper on that in
http://reference.kfupm.edu
Emmanuel Cecchet wrote:
> Jan,
>
>> A couple of nitpicks first:
>>
>> o) the route_tuple_to_child recurses to child tables of child tables,
>> which is undocumented and requires a check_stack_depth() call if it's
>> really desirable
>>
> The recursive call is as deep as the inheritance hierarc
Hi,
ISTM that there's a superfluous curly brace in print_path (which only
gets compiled with -DOPTIMIZER_DEBUG.
Patch attached.
Jan
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c
index bfadcb0..6b2f86c 100644
--- a/src/backend/optimizer/path/allpaths.c
Emmanuel Cecchet wrote:
> Hi Jan,
>
> Here is the updated patch.
> Note that the new code in trigger is a copy/paste of the before row
> insert trigger code modified to use the pointers of the after row
> trigger functions.
Hi,
ok, this version applied, compiled and ran the regression tests fine
Emmanuel Cecchet wrote:
> Hi Jan,
>
> Here is a new version of the patch with the following modifications:
> - used oid list from pg_list.h
> - properly handles triggers and generate an error if needed (updated doc
> as well)
> - added your test cases + extra bad trigger cases
Hi,
that got broke
Hi,
I'll hopefully look at the next version of the patch tommorrow.
Emmanuel Cecchet wrote:
>> o test1.sql always segfaults for me, poking around with gdb suggests
>> it's a case of an uninitialised cache list (another reason to use the
>> builtin one).
>>
> I was never able to reproduce that
Jan Urbański wrote:
> Emmanuel Cecchet wrote:
>> Hi all,
>
> Hi!,
>
>> partitioning option for COPY
> Attached are 3 files that demonstrate problems the patch has.
And the click-before-you-think prize winner is... me.
Test cases attached, see the comments for ex
Emmanuel Cecchet wrote:
> Hi all,
Hi!,
> partitioning option for COPY
Here's the review:
== Submission ==
The patch is contextual, applies cleanly to current HEAD, compiles fine.
The docs build cleanly.
== Docs ==
They're reasonably clear, although they still mention ERROR_LOGGING,
which was t
Petr Jelinek wrote:
> Jan Urbański napsal(a):
>> Dependencies suck, I know..
>>
>
> Cross-database dependencies do.
>
> I had to make target role owner of the default acls which adds some side
> effects like the fact that it blocks DROP ROLE so DROP OWNED
OK, the previous problem went away, but I can still do something like that:
postgres=# create role test;
CREATE ROLE
postgres=# create role test2;
CREATE ROLE
postgres=# create database db;
CREATE DATABASE
postgres=# \c db
psql (8.5devel)
You are now connected to database "db".
db=# alter default
Petr Jelinek wrote:
> I made some more small adjustments - mainly renaming stuff after Tom's
> comment on anonymous code blocks patch and removed one unused shared
> dependency.
Hi,
the patch still has some issues with dependency handling:
postgres=# create role test;
CREATE ROLE
postgres=# crea
Hi,
here's a (late, sorry about that) review:
== Trivia ==
Patch applies cleanly with a few 1 line offsets.
It's unified, not context, but that's trivial.
The patch adds some trailing whitespace, which is not good (git diff
shows it in red, it's easy to spot it). There's also one
hunk that's j
Petr Jelinek wrote:
> So I've been working on solution with which I am happy with (does not
> mean anybody else will be also though).
Hi Petr,
I'm reviewing this patch and after reading it I have some comments.
Unfortunately, when I got to the compiling part, it turned out that the
attached patch
Patch -p1 attached.
Cheers,
Jan
diff --git a/doc/src/sgml/release-8.4.sgml b/doc/src/sgml/release-8.4.sgml
index 184bf47..50d9cb0 100644
--- a/doc/src/sgml/release-8.4.sgml
+++ b/doc/src/sgml/release-8.4.sgml
@@ -104,7 +104,7 @@
Properly show fractional seconds and milliseconds
Tom Lane wrote:
> "Kevin Grittner" writes:
>> I guess the question is whether there is anyone who has had a contrary
>> experience. (There must have been some benchmarks to justify adding
>> geqo at some point?)
>
> The CVS history shows that geqo was integrated on 1997-02-19, which
> I think me
Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>>
>> Alvaro Herrera wrote:
>>> Hi,
>>>
>>> I was having a look at this snippet:
>>> http://wiki.postgresql.org/wiki/Google_Translate
>>> and it turns out that it doesn't work if the result contains non-ASCII
>>> chars. Does anybody know how to fix it?
Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>>
>> Alvaro Herrera wrote:
>>> Hi,
>>>
>>> I was having a look at this snippet:
>>> http://wiki.postgresql.org/wiki/Google_Translate
>>> and it turns out that it doesn't work if the result contains non-ASCII
>>> chars. Does anybody know how to fix it?
Tom Lane wrote:
> Tatsuo Ishii writes:
>> I'm wondering if following behavior of PostgreSQL regarding lock
>> conflict is an expected one. Here's a scenario:
>
>> Session A:
>> BEGIN;
>> SELECT * FROM pg_class limit 1; -- acquires access share lock
>
>> Session B:
>> BEGIN;
>>
Tom Lane wrote:
I started making the changes to increase the default and maximum stats
targets 10X, as I believe was agreed to in this thread:
http://archives.postgresql.org/pgsql-hackers/2008-12/msg00386.php
I came across this bit in ts_typanalyze.c:
/* We want statistic_target * 100 l
rahulg wrote:
I am facing problem in tracing in what events the selectivity
histogram in pg_statistic is stored/updated.
I went through the code in src/backend/commands/analyze.c and got to
see the code computing the histogram but when I tried to trace the
caller of analyze_rel or compute_index_
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
[EMAIL PROTECTED] wrote:
Well whaddya know. It turned out that my new company has a
'Fridays-are-for-any-opensource-hacking-you-like' policy, so I got a
full day to work on the patch.
Hm, does their name start with
[EMAIL PROTECTED] wrote:
Quoting Tom Lane <[EMAIL PROTECTED]>:
I wrote:
... One possibly
performance-relevant point is to use DatumGetTextPP for detoasting;
you've already paid the costs by using VARDATA_ANY etc, so you might
as well get the benefit.
Actually, wait a second. That code does
Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <[EMAIL PROTECTED]> writes:
Simon Riggs wrote:
put it in a file called selfuncs_ts.c so it is similar to the existing
filename?
I followed the pattern of ts_parse.c, ts_utils.c and so on.
Also, I see geo_selfuncs.c. No big deal, though, I can
Simon Riggs wrote:
On Thu, 2008-08-14 at 22:27 +0200, Jan Urbański wrote:
Jan Urbański wrote:
+ * ts_selfuncs.c
Not sure why this is in its own file
I couldn't decide where to put it, so I came up with this.
put it in a file called selfuncs_ts.c so it is similar to the exi
Alvaro Herrera wrote:
Jan Urbański wrote:
Heikki Linnakangas wrote:
Sounds like a plan. In (2), it's even better to detoast the values
lazily. For a typical one-word tsquery, the binary search will only
look at a small portion of the elements.
Hm, how can I do that? Toast is still
Jan Urbański wrote:
Heikki Linnakangas wrote:
Jan Urbański wrote:
So right now the idea is to:
(1) pre-sort STATISTIC_KIND_MCELEM values
(2) build an array of pointers to detoasted values in tssel()
(3) use binary search when looking for MCELEMs during tsquery analysis
Sounds like a plan
Heikki Linnakangas wrote:
Jan Urbański wrote:
So right now the idea is to:
(1) pre-sort STATISTIC_KIND_MCELEM values
(2) build an array of pointers to detoasted values in tssel()
(3) use binary search when looking for MCELEMs during tsquery analysis
Sounds like a plan. In (2), it's
Heikki Linnakangas wrote:
Jan Urbański wrote:
So right now the idea is to:
(1) pre-sort STATISTIC_KIND_MCELEM values
(2) build an array of pointers to detoasted values in tssel()
(3) use binary search when looking for MCELEMs during tsquery analysis
Sounds like a plan. In (2), it's
Heikki Linnakangas wrote:
Jan Urbański wrote:
Not good... Shall I try sorting pg_statistics arrays on text values
instead of frequencies?
Yeah, I'd go with that. If you only do it for the new
STATISTIC_KIND_MCV_ELEMENT statistics, you shouldn't need to change any
other code.
O
Heikki Linnakangas wrote:
Jan Urbański wrote:
26763 3.5451 AllocSetCheck
Make sure you disable assertions before profiling.
Awww, darn. OK, here goes another set of results, without casserts this
time.
=== CVS HEAD ===
number of clients: 10
number of transactions per client: 10
Heikki Linnakangas wrote:
Jan Urbański wrote:
through it. The only tiny ugliness is that there's one function used
for qsort() and another for bsearch(), because I'm sorting an array of
texts (from pg_statistic) and I'm binary searching for a lexeme
(non-NULL terminated str
Tim Hawes wrote:
@Jan:
It appears the cstring_to_text function is unique to the latest
PostgreSQL code. I do not have a def for that for PostgreSQL 8.2, and
Oh, I'm sorry, I forgot about that. cstring_to_text has been added only
recently (it's not even it 8.3, silly me).
Datum pl_master
Tim Hawes wrote:
Hello all,
I am trying to write an extension in C that returns a simple environment
variable. The code compiles without any complaint or warning, and it
loads fine into the database, however, when I run the function, I get
disconnected from the server.
Here is my C code:
#
Peter Eisentraut wrote:
On Monday 11 August 2008 16:23:29 Jan Urbański wrote:
Often clients want their searches to be
accented-or-language-specific letters insensitive. So searching for
'łódź' returns 'lodz'. So the use case is there (in fact, the lack of
such facility
201 - 300 of 348 matches
Mail list logo