On Wed, 9 May 2007, Andrew Dunstan wrote:
Karel Gardas wrote:
[...]
I'd like to look at a possibility of integrating OpenPMF
(http://www.openpmf.org) with the PostgreSQL.
[...]
Exactly what is open about this product other than the name? It looks
closed and proprietary to me.
It was
Tom Lane írta:
After some more study of the SQL spec, the distinction between GENERATED
ALWAYS AS IDENTITY and GENERATED BY DEFAULT AS IDENTITY is not what
I thought it was.
* As far as I can find from the spec, there is *no* difference between
the two cases for INSERT commands. The rule is
Zoltan Boszormenyi írta:
The quoted SIGMOD paper mentioned that specifying a value
for a generated column should raise an error in INSERT but
this behaviour is not mentioned by the standard.
I found it now, I haven't read hard enough before.
SQL:2003, section 14.8, syntax rules:
10) If
Hello again,
I got the opclass for the index and it looks like it is a default one
myvideoindex=# select pg_opclass.*, pg_type.typname
myvideoindex-# from pg_index, pg_opclass, pg_type
myvideoindex-# where pg_index.indexrelid =
'idx_nonnulls_myintarray_int4_gin'::regclass
myvideoindex-#
On Wed, May 09, 2007 at 12:46:52PM +0100, Dave Page wrote:
Oh, hang on... Vista's new 'security' features include popups that ask
permission from the user before running any installers. One of the more
basic checks they use is the filename - *anything* called setup.exe will
cause user
Michael Meskes wrote:
On Wed, May 09, 2007 at 12:46:52PM +0100, Dave Page wrote:
Oh, hang on... Vista's new 'security' features include popups that ask
permission from the user before running any installers. One of the more
basic checks they use is the filename - *anything* called setup.exe
In reference to the seq scans roadmap, I have just submitted
a patch that addresses some of the concerns.
The patch does this:
1. for small relation (smaller than 60% of bufferpool), use
the current logic 2. for big relation:
- use a ring buffer in heap scan
- pin first
Zeugswetter Andreas ADI SD wrote:
In reference to the seq scans roadmap, I have just submitted
a patch that addresses some of the concerns.
The patch does this:
1. for small relation (smaller than 60% of bufferpool), use
the current logic 2. for big relation:
- use a ring buffer in
Also, that patch doesn't address the VACUUM issue at all. And
using a small fixed size ring with scans that do updates can
be devastating. I'm experimenting with different ring sizes
for COPY at the moment. Too small ring leads to a lot of WAL
flushes, it's basically the same problem we
Zeugswetter Andreas ADI SD wrote:
Also, that patch doesn't address the VACUUM issue at all. And
using a small fixed size ring with scans that do updates can
be devastating. I'm experimenting with different ring sizes
for COPY at the moment. Too small ring leads to a lot of WAL
flushes, it's
Hiroshi Inoue wrote:
Alvaro Herrera wrote:
Robert Treat wrote:
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
Maybe it's BSD which is different from the license of psqlodbc (LGPL).
Is there no problem with their coexistence ?
Or is it
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Robert Treat wrote:
It's generally a very bad idea for a BSD licensed project to include lgpl
licensed code
Psqlodbc package is LGPL licensed and seems to have little problem to
include copy of BSD licensed code as a part of it.
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Tom Lane írta:
This means that GENERATED BY DEFAULT AS IDENTITY is not at all
equivalent to our historical behavior for SERIAL columns and hence we
cannot merge the two cases.
Yes, they are equivalent if you read 5IWD2-02-Foundation-2006-04.pdf
Alvaro Herrera wrote:
Hiroshi Inoue wrote:
Alvaro Herrera wrote:
Robert Treat wrote:
On Monday 07 May 2007 15:52, Joshua D. Drake wrote:
Andrew Dunstan wrote:
Hiroshi Inoue wrote:
snip
Of course, the developer who owns the LGPL-licensed copyright is free to
relicense his work under a
On Thu, May 10, 2007 at 11:05:39AM +0100, Dave Page wrote:
P.S.: More on the other problem later.
OK.
Dave, I just committed some small changes to get additional error
logging. Hopefully this enables me to find out where exactly the error
is coming up. If possible could you please restart a
Just got the report below in pgsql-es-ayuda. He says his logs files are
filled with 50 MB of the error message
LOG: SSL SYSCALL error: Unknown winsock error 10004
I looked up 10004 and apparently it's WSAEINTR, according to
http://msdn2.microsoft.com/en-us/library/aa924071.aspx
Michael Meskes wrote:
On Thu, May 10, 2007 at 11:05:39AM +0100, Dave Page wrote:
P.S.: More on the other problem later.
OK.
Dave, I just committed some small changes to get additional error
logging. Hopefully this enables me to find out where exactly the error
is coming up. If possible
Heikki Linnakangas wrote:
But all these assumptions need to be validated. I'm setting up tests
with different ring sizes and queries to get a clear picture of this:
- VACUUM on a clean table
- VACUUM on a table with 1 dead tuple per page
- read-only scan, large table
- read-only scan, table
Dear mailing list,
I have got a problem installing Postgres 8.2.3 on Windows XP Pro having
all the latest updates.
All postgres installations, folders and the serviceaccount have been
removed before so that it was clean installation.
The following steps lead to a reproducible result on a few
Heikki Linnakangas wrote:
However, it caught me by total surprise that the performance with 1
buffer is so horrible. Using 2 buffers is enough to avoid whatever the
issue is with just 1 buffer. I have no idea what's causing that. There
must be some interaction that I don't understand.
Ok, I
The patch has no effect on scans that do updates. The
KillAndReadBuffer routine does not force out a buffer if the dirty
bit is set. So updated pages revert to the current performance
characteristics.
-cktan
GreenPlum, Inc.
On May 10, 2007, at 5:22 AM, Heikki Linnakangas wrote:
When planning queries with a large IN expression in the WHERE clause,
the planner transforms the IN list into a scalar array expression. In
clause_selectivity(), we estimate the selectivity of the ScalarArrayExpr
by calling scalararraysel(), which in turn estimates the selectivity of
*each* array
Sorry, 16x8K page ring is too small indeed. The reason we selected 16
is because greenplum db runs on 32K page size, so we are indeed
reading 128K at a time. The #pages in the ring should be made
relative to the page size, so you achieve 128K per read.
Also agree that KillAndReadBuffer
Neil Conway wrote:
Clearly, the current approach is fine when the array is small -- perhaps
for arrays above a certain number of elements, we could switch to
randomly sampling array elements, estimating their selectivities, and
then using that information to infer the estimated selectivity of
Neil Conway [EMAIL PROTECTED] writes:
When planning queries with a large IN expression in the WHERE clause,
the planner transforms the IN list into a scalar array expression. In
clause_selectivity(), we estimate the selectivity of the ScalarArrayExpr
by calling scalararraysel(), which in turn
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Tom Lane
Sent: Thursday, May 10, 2007 11:53 AM
To: Neil Conway
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Planning large IN lists
Neil Conway [EMAIL PROTECTED] writes:
Dave Page wrote:
Michael Meskes wrote:
On Thu, May 10, 2007 at 11:05:39AM +0100, Dave Page wrote:
P.S.: More on the other problem later.
OK.
Dave, I just committed some small changes to get additional error
logging. Hopefully this enables me to find out where exactly the error
is coming up.
On May 8, 7:16 am, [EMAIL PROTECTED] (Abraham, Danny) wrote:
Hi,
I am migrating from Sybase to Postgres.
3. Who is the guy to ask about a feature like startup migrate in ORACLE?
You could check out EnterpriseDB, which is based on Postgres and
provides an Oracle compatibility layer. That
On Thu, 2007-05-10 at 10:11 -0400, Tom Lane wrote:
As for GENERATED ALWAYS AS (expr), now that we understand that it's not
supposed to define a virtual column, what's the point? You can get the
same behavior with a trivial BEFORE INSERT/UPDATE trigger that
recomputes the derived value, and
On Tue, 2007-05-08 at 17:16 +0300, Abraham, Danny wrote:
I am migrating from Sybase to Postgres.
trying to get a hold on the issue of future releases feature list.
1. Where can I find the feature list for 8.3 ? When is it expected?
2. And for 8.4?
3. Who is the guy to ask about a
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2007-05-10 at 10:11 -0400, Tom Lane wrote:
As for GENERATED ALWAYS AS (expr), now that we understand that it's not
supposed to define a virtual column, what's the point?
We do need virtual columns, whether the spec requires them or not.
Agreed,
31 matches
Mail list logo
