"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
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
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
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
> > 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
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
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
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
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
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
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
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
[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
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.
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
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
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)
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
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" <[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
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
> 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
[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
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
"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
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
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
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 <[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
>>
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
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
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
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
"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
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
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
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..
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
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
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
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
>
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
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
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
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
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
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
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
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
49 matches
Mail list logo
