Bruce,
I sent you link to my wiki page with summary of changes
http://www.sai.msu.su/~megera/wiki/ts_changes
Your documentation looks rather old.
Oleg
On Tue, 24 Jul 2007, Bruce Momjian wrote:
I have added more documentation to try to show how full text search is
used by user tables. I thin
I have added more documentation to try to show how full text search is
used by user tables. I think this the documentaiton is almost done:
http://momjian.us/expire/fulltext/HTML/textsearch-tables.html
---
Oleg Bart
Stephen Ince wrote:
> I am looking to embed postgres into an application on windows. I am
> fine with it being a separate service. Here is what I am looking to do.
> Any help would be greatly appreciated.
>
This is the wrong list to ask this question. Next time try general list.
What you're look
Hi,
I am looking to embed postgres into an application on windows. I am fine
with it being a separate service. Here is what I am looking to do. Any help
would be greatly appreciated.
1) Install postgres silently. Libs (dll) and data files.
a) What are the minimum files dll.
b) What .conf
Andrei Kovalevski wrote:
Andrew Dunstan wrote:
Dave Page wrote:
Andrew Dunstan wrote:
On a somewhat related note, I have had spectacular lack of success
in getting either MSVC or MinGW builds to work on Vista - so much
so that I have currently abandoned my attempts on that platform and
I r
Magnus Hagander <[EMAIL PROTECTED]> writes:
> The DLLIMPORT definition used on Win32 conflicts with the headers in TCL,
> at least, and possibly others.
> One way to fix it is similar to the HAVE_xyz ones that I talk about in my
> other email. Another way to do it would be for us to use PGDLLIMPOR
Andrew Dunstan wrote:
Dave Page wrote:
Andrew Dunstan wrote:
On a somewhat related note, I have had spectacular lack of success
in getting either MSVC or MinGW builds to work on Vista - so much so
that I have currently abandoned my attempts on that platform and I
resorted to resuscitating an
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> The attached file removes this by undefing the macros before we include the
>> kerberos files. But this is perhaps just too ugly to deal with and we
>> should live with the warnings instead?
>
> Ick. I don't like any of these patche
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Marko Kreen wrote:
>> So we can revisit the issue when we are ready to drop
>> support for 0.9.6x.
> the last openssl 0.9.6 release was in march 2004 and 0.9.7 is available
> since early 2003 - I don't think dropping support for it in 8.3+ would
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> While I don't have any very strong objection to putting an ORDER BY
>> on these particular queries, I'm worried about how many other regression
>> tests will now start showing random failures. We have an awful lot
>> of small tables i
On 7/24/07, Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote:
Marko Kreen wrote:
> So we can revisit the issue when we are ready to drop
> support for 0.9.6x.
the last openssl 0.9.6 release was in march 2004 and 0.9.7 is available
since early 2003 - I don't think dropping support for it in 8.3+ wo
It looks like you need a customized version of AExpr Node.
In the backend parser, an AExpr Node is constructed against each given
WHERE expression. You can store the weight along with the expression.
Further, don't forget to upgrade the copy functions and equal
functions for AExpr if you want to t
Marko Kreen wrote:
> On 7/24/07, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
>> Marko Kreen wrote:
>> > NAK. The fix is broken because it uses EVP interface. EVP is not
>> > a general-purpose interface because not all valid keys for cipher
>> > pass thru it. Only key-lengths used in SSL will work..
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>> Gregory Stark wrote:
What really has to happen is it should run analyze on all tables
together in a single transaction and commit all the new stats together
Dave Page wrote:
Andrew Dunstan wrote:
On a somewhat related note, I have had spectacular lack of success in
getting either MSVC or MinGW builds to work on Vista - so much so
that I have currently abandoned my attempts on that platform and I
resorted to resuscitating an old XP box for testi
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Gregory Stark wrote:
>>> What really has to happen is it should run analyze on all tables
>>> together in a single transaction and commit all the new stats together.
>>> Out-of-sync stats can be worse than out-o
On Jul 23, 2007, at 11:30 PM, Simon Riggs wrote:
On Tue, 2007-07-24 at 13:04 +0900, Tatsuo Ishii wrote:
I noticed in 8.3 there are chances where we can avoid WAL logging.
For
example, 8.3's pgbench was modified to use TRUNCATE right before
COPY. Is there any documentation which describes that
On 7/24/07, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
Marko Kreen wrote:
> NAK. The fix is broken because it uses EVP interface. EVP is not
> a general-purpose interface because not all valid keys for cipher
> pass thru it. Only key-lengths used in SSL will work...
I'm not openssl expert, but
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What I don't understand is what you mean with it "obliterating" the
> stats for a table.
The point seems to be that if there is no pg_statistic data for these
tables, we fall back to default estimates of the selectivity of the
WHERE clauses, and those p
Tom Lane wrote:
> While I don't have any very strong objection to putting an ORDER BY
> on these particular queries, I'm worried about how many other regression
> tests will now start showing random failures. We have an awful lot
> of small tables in the tests ...
Maybe what we could do is set h
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I saw what I think was the identical failure last night on my own
>> machine, but it wasn't repeatable. Evidently the planner is changing to
>> a different plan for those queries, but why has this only started
>>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> What really has to happen is it should run analyze on all tables
>> together in a single transaction and commit all the new stats together.
>> Out-of-sync stats can be worse than out-of-date stats.
> One problem with that is that
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> >> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
> >> any ideas ?
> >
> > I saw what I think was the identical failure last night on my
On Jul 24, 2007, at 1:02 AM, Gregory Stark wrote:
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
We didn't, but while I agree with the idea, I think 5% is too low. I
don't want autovacuum to get excessively aggressive. Is 10% not
enough?
Well let me flip it around. Would you think a default
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
>> any ideas ?
>
> I saw what I think was the identical failure last night on my own
> machine, but it wasn't repeat
Hi all,
I want to pass additional weight info from the WHERE clause to the executor and
I hope someone can help me with this.
I accept clauses like the following
WHERE (foo='a'){1}
WHERE (foo='a'){1} OR (bar='b'){2}
WHERE ((foo='a'){1} OR (bar='b'){2})){42} OR (baz='c'){3}
where the {} takes a
[EMAIL PROTECTED] writes:
> Interesting, what do you mean by Plan trees are 'read only' now? Is it the
> distinction between Plan trees and their corresponding PlanState nodes that
> indicate the 'read only' behaviour and the 'writeable' state of the Plan,
> respectively, that was introduced at
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
> any ideas ?
I saw what I think was the identical failure last night on my own
machine, but it wasn't repeatable. Evidently the planner is changing to
a dif
Von: Tom Lane <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] writes:
> > WARNING: could not dump unrecognized node type: 404
> > ExecQual: qual is (
> >{
> >}
> > )
>
> Yeah, that code is toast, we probably ought to remove it. It hasn't
> worked since the changes to make the executor treat plan
"Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
That's just a faulty test:
SELECT t.d1 + i.f1 AS "102" FROM TIMESTAMP_TBL t, INTERVAL_TBL i
WHERE t.d1 BETWEEN '1990-01-01' AND '2001-01-01'
AND i.f
Zdenek Kotala wrote:
Stefan Kaltenbrunner wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
any ideas ?
This test is very sensitive to floating point operations behavior. Any
gcc, libc update on this machine?
nope - in fact nobody was even
Stefan Kaltenbrunner wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
any ideas ?
This test is very sensitive to floating point operations behavior. Any
gcc, libc update on this machine?
Zdenek
---(e
Stefan Kaltenbrunner wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
clownfish just hit the same problem:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=clownfish&dt=2007-07-24%2013:08:29
Stefan
---(end of broadcast)
Marko Kreen wrote:
On 7/24/07, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
However, on default installation (which is commonly used) it is a
problem. Regression test cannot be fixed because it tests strong
ciphers, but there two very strange issue:
1) First issue is blowfish cipher. Because pg
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
any ideas ?
Stefan
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Magnus Hagander <[EMAIL PROTECTED]> writes:
> The attached file removes this by undefing the macros before we include the
> kerberos files. But this is perhaps just too ugly to deal with and we
> should live with the warnings instead?
Ick. I don't like any of these patches.
[EMAIL PROTECTED] writes:
> WARNING: could not dump unrecognized node type: 404
> ExecQual: qual is (
>{
>}
> )
Yeah, that code is toast, we probably ought to remove it. It hasn't
worked since the changes to make the executor treat plan trees as
read-only. Making it work would require t
Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> ... BMI is not useful at all
>> for PKs, whilst GIT is specifically designed to handle them.
>
> This seems a strange statement, because GIT doesn't look particularly
> efficient for unique indexes AFAICS. In the worst case you'd have
On 7/24/07, Zdenek Kotala <[EMAIL PROTECTED]> wrote:
Stefan reported me that prcrypto regression test fails on solaris 10
with openssl support. I investigated this problem and the result is that
Solaris 10 delivers only support for short keys up to 128. Strong crypto
(SUNWcry and SUNWcryr package
On Mon, 2007-07-23 at 23:11 +0100, Simon Riggs wrote:
> On Mon, 2007-07-23 at 17:19 -0400, Tom Lane wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > ... BMI is not useful at all
> > > for PKs, whilst GIT is specifically designed to handle them.
> >
> > This seems a strange statement, bec
Stefan reported me that prcrypto regression test fails on solaris 10
with openssl support. I investigated this problem and the result is that
Solaris 10 delivers only support for short keys up to 128. Strong crypto
(SUNWcry and SUNWcryr packages) is available on web download pages. (It
is resul
The DLLIMPORT definition used on Win32 conflicts with the headers in TCL,
at least, and possibly others.
One way to fix it is similar to the HAVE_xyz ones that I talk about in my
other email. Another way to do it would be for us to use PGDLLIMPORT
instead of DLLIMPORT. That way we'd be sure not to
When building with Kerberos support (or GSSAPI, but not SSPI) on Win32, a
whole bunch of warnings come out due to redefinitions of macros in the
kerberos headers. The reason for this is that Kerberos leaks the
HAVE_ macros from autoconf into the header files that are
included by PostgreSQL.
The a
On Tue, 2007-07-24 at 18:45 +0900, Tatsuo Ishii wrote:
> > > I noticed in 8.3 there are chances where we can avoid WAL logging. For
> > > example, 8.3's pgbench was modified to use TRUNCATE right before
> > > COPY. Is there any documentation which describes that kind of
> > > techniques? If there's
> > I noticed in 8.3 there are chances where we can avoid WAL logging. For
> > example, 8.3's pgbench was modified to use TRUNCATE right before
> > COPY. Is there any documentation which describes that kind of
> > techniques? If there's none, I would volunteer the work to create such
> > a document
Hi all,
I am using version 8.2.4 of the source and compiled it with
both OPTIMIZER_DEBUG and EXEC_EVALDEBUG enabled to take a look
at how quals are evaluated by the executor.
However, when I issue a query like
SELECT name FROM city WHERE population < 10 LIMIT 10;
I get the following debug o
On Tue, 2007-07-24 at 13:04 +0900, Tatsuo Ishii wrote:
> I noticed in 8.3 there are chances where we can avoid WAL logging. For
> example, 8.3's pgbench was modified to use TRUNCATE right before
> COPY. Is there any documentation which describes that kind of
> techniques? If there's none, I would
On Tue, 2007-07-24 at 13:50 +0900, ITAGAKI Takahiro wrote:
> The GucContext of log_autovacuum is PGC_BACKEND in the CVS HEAD,
> but should it be PGC_SIGHUP? We cannot modify the variable on-the-fly
> because the parameter is used only by autovacuum worker processes.
> The similar variables, like au
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> We didn't, but while I agree with the idea, I think 5% is too low. I
> don't want autovacuum to get excessively aggressive. Is 10% not enough?
Well let me flip it around. Would you think a default fillfactor of 10% would
be helpful or overkill? I
49 matches
Mail list logo
