On Jan 22, 2008 11:22 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > So I wonder why the stats were so bad... I didn't update the data at
> > all after the initial import. Any idea?
>
> Hmm, perhaps the analyze was done with the default statistic target (10)?
It's set to 30 in the postgresql.co
Guillaume Smet escribió:
> It seems that autovacuum took care of them just after the import which
> is what I expected:
[...]
> So I wonder why the stats were so bad... I didn't update the data at
> all after the initial import. Any idea?
Hmm, perhaps the analyze was done with the default stati
On Jan 22, 2008 9:52 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> No, autovacuum should have taken care of it. I would be interesting in
> knowing why it didn't.
I just dropped the database on monday morning and import it again.
Nothing really fancy.
It seems that autovacuum took care of them
This patch is in error. Please ignore. I have already sent the corrected patch.
Thanks,
wt
On Jan 22, 2008 12:50 PM, Warren Turkal <[EMAIL PROTECTED]> wrote:
> I added TimeOffset and DateOffset typedefs to get rid of the instances
> using the HAVE_INT64_TIMESTAMP define being used to determine th
I added TimeOffset and DateOffset typedefs to get rid of the instances
using the HAVE_INT64_TIMESTAMP define being used to determine the
types of variables or functions in timestamp.c.
---
src/backend/utils/adt/timestamp.c | 77 +++-
src/include/utils/timestamp.h
Here is a fixed patch for the timestamp refactor. I apologize for sending the
wrong patch earlier.
I would like to get some comments on if this patch is heading in the right
direction. Here's the proposal for what I am doing:
Proposal for Refactoring of Timestamp Datatype
Goal:
The primary go
Guillaume Smet escribió:
> On Jan 22, 2008 8:28 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > I'd expect 8.1 to make about the same estimate given the same stats,
> > so I think it's not looking at the same stats.
>
> Yep, the statistics were the problem, sorry for the noise. The query
> performs i
I added TimeOffset and DateOffset typedefs to get rid of the instances
using the HAVE_INT64_TIMESTAMP define being used to determine the
types of variables or functions in timestamp.c.
---
src/backend/utils/adt/timestamp.c | 77 +++--
src/include/utils/timestamp.h
>
> Agreed. I think Pavel Stehule was doing some experiments with them, I
> don't know if he got anywhere.
>
I did only first research. Any hack is possible - you can stack
current transaction, but real implementation needs similar work like
nested transaction :( and it is too low level for me. A
On Jan 22, 2008 8:28 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> The only way the merge join could have an estimated cost that's barely
> 1% of the estimate for one of its inputs is if the planner thinks the
> merge will stop after reading only 1% of that input, ie, the largest
> a.numasso value is o
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> While testing RC2 on the new servers of one of our customers, I found
> a query really slow on the new server which is quite fast on the old
> box currently in production (production is 8.1 at the moment).
Have you ANALYZEd these tables lately? It lo
> On Tue, 2008-01-22 at 10:02 -0600, Roberts, Jon wrote:
> > Maybe someone could enhance this concept to include it with the core
> > database to provide autonomous transactions.
>
> I agree that autonomous transactions would be useful, but doing them via
> dblink is a kludge.
Kludge or hack but
Neil Conway wrote:
> On Tue, 2008-01-22 at 10:02 -0600, Roberts, Jon wrote:
> > Maybe someone could enhance this concept to include it with the core
> > database to provide autonomous transactions.
>
> I agree that autonomous transactions would be useful, but doing them via
> dblink is a kludge. I
On Tue, 2008-01-22 at 10:02 -0600, Roberts, Jon wrote:
> Maybe someone could enhance this concept to include it with the core
> database to provide autonomous transactions.
I agree that autonomous transactions would be useful, but doing them via
dblink is a kludge. If we're going to include anythi
Hi -hackers,
While testing RC2 on the new servers of one of our customers, I found
a query really slow on the new server which is quite fast on the old
box currently in production (production is 8.1 at the moment).
If I set enable_nestloop to off, the query is fast (the plan is
different from the
--
From: "Tom Lane" <[EMAIL PROTECTED]>
Sent: Monday, January 21, 2008 10:13 PM
To: "Sam Mason" <[EMAIL PROTECTED]>
Cc:
Subject: Re: [HACKERS] Polyphase Merge
I agree --- having to read the run back from external storage, only to
write it out a
On Wednesday 16 January 2008 08:32, Andrew Dunstan wrote:
> ( Slightly OT - chkpass uses crypt(). Maybe that should be upgraded to
> use md5 or some more modern hashing function. )
Some versions of crypt() will generate md5 hashes if you start the salt with
$1$$. I know this to work on FreeBSD,
I really needed this functionality in PostgreSQL. A common use for
autonomous transactions is error logging. I want to log sqlerrm in a
function and raise an exception so the calling application knows there is an
error and I have it logged to a table.
I figured out a way to "hack" an autono
Tom Lane wrote:
> What I propose we do about this is put the same check into TRUNCATE,
> CLUSTER, and REINDEX that is already in ALTER TABLE, namely that we
> reject the command if the current transaction is already holding
> the table open.
+1.
> The issue Steven directly complained of is a po
cinu wrote:
Hi All,
I was running the run_Build.pl script that is specific
to Buildfarm and encountered errors. I am listing out
the names of the logfiles and the errors that I have
seen.
Can anyone give me some clarity on these errors?
Even though these errors are existing, at the end the
l
I suggest make a distinction between DDL and DML locks. A DDL lock would be
required for a TRUNCATE, CREATE, ALTER, DROP, REPLACE, etc while DML is just
insert, update, and delete.
A TRUNCATE (or any DDL activity) should wait until all DML activity is
committed before it can acquire an exclusive
On Mon, Jan 21, 2008 at 04:13:32PM -0500, Tom Lane wrote:
> Sam Mason <[EMAIL PROTECTED]> writes:
> > It's really up to you to find answers to these questions, especially
> > the first one. Once you've designed an efficient algorithm then the
> > second point (which I'm interpreting as how you'd g
Does anyone has a solution for pljava.dll not loading? I see the same issue
listed
for 8.3-rc1, supposedly fixed in 8.3-rc3. But I need something that works
for
8.2
C:\Program Files\PostgreSQL\8.2\bin>"%JAVA_HOME%/bin/java" -cp
../../../../pljav
a-i686-pc-mingw32-pg8.2-1.3.1/deploy.jar;../jdbc/po
Am Montag, 21. Januar 2008 schrieb Tom Lane:
> %_topdir /home/tgl/rpmwork
>
> then create the directory ~/rpmwork and under it the five directories
> BUILD/ RPMS/ SOURCES/ SPECS/ SRPMS/
Some distributions set up their standard build areas under /usr/src to be
world writeable (sticky bi
Hi All,
I was running the run_Build.pl script that is specific
to Buildfarm and encountered errors. I am listing out
the names of the logfiles and the errors that I have
seen.
Can anyone give me some clarity on these errors?
Even though these errors are existing, at the end the
latest version is
25 matches
Mail list logo
