I noticed something odd when trying to use the row-wise comparison
mentioned in the release notes for 8.2 and in the docs
http://developer.postgresql.org/pgdocs/postgres/functions-comparisons.html#ROW-WISE-COMPARISON
This sets up a suitable test:
create type myrowtype AS (a integer, b integer);
Hi,
Currently we have enable_sig_alarm() which provides millisecond level
granularity in specifying delay. I tried using it by just specifying
nonzero value for the timeval.it_value.tv_usec field before calling
setitimer, but didn't seem to work well.
Do we have any function in the postgres
At least according to [1], kernel AIO on Linux still doesn't work
for
buffered (i.e. non-O_DIRECT) files. There have been patches
available
for quite some time that implement this, but I'm not sure when they
are likely to get into the mainline kernel.
-Neil
[1]
Am Freitag, 20. Oktober 2006 00:32 schrieb Tom Lane:
So I'm inclined to leave the behavior as-is. The documentation for
log_statement already says
Note: Statements that generate syntax errors are not logged. Set
log_min_error_statement to error to log such statements.
Oh, I
Neil Conway wrote:
Why does adminpack install functions into pg_catalog? This is
inconsistent with the rest of the contrib/ packages, not to mention the
definition of pg_catalog itself (which ought to hold builtin object
definitions). And as AndrewSN pointed out on IRC, it also breaks
Hi, Mark,
Mark Woodward wrote:
My question, is it a syntactic technicality that PostgreSQL asks for a
group by, or a bug in the parser?
I think that it's a lack of special-casing the = operator. Imagine
where ycis_id15 or where ycis_id @| $RECTANGLE or other (probably
user defined)
Am Freitag, 20. Oktober 2006 09:13 schrieb Adrian Maier:
It would have been much more convenient to see the bad queries in
the logs ...
I think you are missing the point of this discussion. All the erroneous
queries are logged. The question is merely under what configuration.
--
Peter
Zeugswetter Andreas ADI SD wrote:
An improvement is going into 2.6.19 to handle asynchronous
vector reads and writes. This was covered by Linux Weekly
News a couple of weeks ago:
http://lwn.net/Articles/201682/
That is orthogonal. We don't really need vector io so much, since we
Hi, Martijn,
Martijn van Oosterhout wrote:
On Wed, Oct 18, 2006 at 11:36:44AM -0700, Jeff Davis wrote:
What's being suggested simply violates common sense. Basically:
if (a = b) then (a||c = b||c)
If a is 'x' and b is 'x' and c is NULL, the above statement doesn't hold
in PostgreSQL.
On 10/19/06, Tom Lane [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
When setting log_statement = 'all', statements that fail parsing are not
logged.
Is that intentional?
The 'mod' and 'ddl' settings obviously can't be handled until after
basic parsing. We could create
Hi, Devrim,
Devrim GUNDUZ wrote:
I have almost finished working on multiple rpm + postmaster issue today.
The spec file and patches in pgsqlrpms cvs work almost as expected and
does some preliminary work about multiple postmaster installation issue
(we can build the rpms and they are
Am Freitag, 20. Oktober 2006 15:19 schrieb Markus Schaber:
Devrim GUNDUZ wrote:
I have almost finished working on multiple rpm + postmaster issue today.
The spec file and patches in pgsqlrpms cvs work almost as expected and
does some preliminary work about multiple postmaster installation
Hi Markus,
On Fri, 2006-10-20 at 15:19 +0200, Markus Schaber wrote:
Did you look at how the debian guys handle this?
No, but I believe what Peter wrote two days before was a solution of
Debian guys.
Regards,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL
Hi Peter,
On Fri, 2006-10-20 at 15:37 +0200, Peter Eisentraut wrote:
Did you look at how the debian guys handle this?
[EMAIL PROTECTED]:~$ ls -1 /usr/share/locale/de/LC_MESSAGES/p*
snip
Quick question: Could you please point me a way to change the names
of .mo files and make each
On 10/20/06, Jeremy Drake [EMAIL PROTECTED] wrote:
I noticed something odd when trying to use the row-wise comparison
mentioned in the release notes for 8.2 and in the docs
http://developer.postgresql.org/pgdocs/postgres/functions-comparisons.html#ROW-WISE-COMPARISON
This sets up a suitable
Devrim GUNDUZ wrote:
Hi Peter,
On Fri, 2006-10-20 at 15:37 +0200, Peter Eisentraut wrote:
Did you look at how the debian guys handle this?
[EMAIL PROTECTED]:~$ ls -1 /usr/share/locale/de/LC_MESSAGES/p*
snip
Quick question: Could you please point me a way to change the names
of
Jeremy Drake [EMAIL PROTECTED] writes:
select rowval from myrowtypetable ORDER BY ROW((rowval).*) USING ;
ERROR: operator does not exist: record record
This isn't required by the spec, and it's not implemented. I don't
see that it'd give any new functionality anyway, since you can always
do
Hi Alvaro,
On Fri, 2006-10-20 at 10:53 -0300, Alvaro Herrera wrote:
The package files are here:
http://packages.debian.org/unstable/misc/postgresql-8.1
you can find the patch Debian applies following a link below (the
diff.gz), on which you see the method for doing this.
Thanks. Let
NikhilS [EMAIL PROTECTED] writes:
Do we have any function in the postgres codebase which provides microseconds
level of delay coupled with SIGALRM support?
On most Unixen the resolution of SIGALRM is millisecond(s), so you'd be
living in a dream world if you assumed it would work.
On Fri, Oct 20, 2006 at 11:13:33AM +0530, NikhilS wrote:
Good idea, but async i/o is generally poorly supported.
Async i/o is stably supported on most *nix (apart from Linux 2.6.*) plus
Windows.
Guess it would be still worth it, since one fine day 2.6.* will start
supporting it properly too.
Am Freitag, 20. Oktober 2006 15:53 schrieb Alvaro Herrera:
ISTM these parts of that patch should be applied to our code:
+--- postgresql-8.1beta3-old/src/bin/pg_controldata/pg_controldata.c
2005-10-03 02:28:41.0 +0200
postgresql-8.1beta3/src/bin/pg_controldata/pg_controldata.c
Alvaro Herrera [EMAIL PROTECTED] writes:
ISTM these parts of that patch should be applied to our code:
+--- postgresql-8.1beta3-old/src/bin/pg_controldata/pg_controldata.c
2005-10-03 02:28:41.0 +0200
postgresql-8.1beta3/src/bin/pg_controldata/pg_controldata.c
2005-10-13
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
ISTM these parts of that patch should be applied to our code:
+--- postgresql-8.1beta3-old/src/bin/pg_controldata/pg_controldata.c
2005-10-03 02:28:41.0 +0200
I have a setup in which a table has been partitioned into 30 partitions on
type (1 -30), however no matter what I do i can't make the planner try to use
constraint exclusion on it. As you can see by the plan, it figures that there
is at least 1 rows in each partition (Which there is not). Also
db=# \d s_ps.tbl_ps_type_1
Table s_ps.tbl_ps_type_1
...
Check constraints:
tbl_ps_typ_1_type_check CHECK (type = 1)
Inherits: tbl_ps
...
myyearbook=# EXPLAIN ANALYZE SELECT uid FROM tbl_ps WHERE
type = 1 and
normalized_text='bush';
Darcy Buskermolen [EMAIL PROTECTED] writes:
I have a setup in which a table has been partitioned into 30 partitions on
type (1 -30), however no matter what I do i can't make the planner try to use
constraint exclusion on it.
Do you have constraint_exclusion turned on? What are the check
Good idea, but async i/o is generally poorly supported.
Only if it can be shown that async I/O actually results in an
improvement.
sure.
fix it. So, what is the bottleneck? Is PostgreSQL unable to
max out the I/O bandwidth? Where? Why?
Yup, that would be the scenario where it helps
On Friday 20 October 2006 08:26, Tom Lane wrote:
Darcy Buskermolen [EMAIL PROTECTED] writes:
I have a setup in which a table has been partitioned into 30 partitions
on type (1 -30), however no matter what I do i can't make the planner try
to use constraint exclusion on it.
Do you have
Darcy Buskermolen [EMAIL PROTECTED] writes:
Yes CE is on (you can see it in the session paste). The other child tables
have simular CHECK's of type=2, type=3, type=4 and so on.. 1 for each of the
30 tables.
[ looks again... ] Oh, here's your problem:
type | smallint
On Friday 20 October 2006 09:27, Tom Lane wrote:
Darcy Buskermolen [EMAIL PROTECTED] writes:
Yes CE is on (you can see it in the session paste). The other child
tables have simular CHECK's of type=2, type=3, type=4 and so on.. 1 for
each of the 30 tables.
[ looks again... ] Oh, here's
On Fri, Oct 20, 2006 at 05:37:48PM +0200, Zeugswetter Andreas ADI SD wrote:
Yup, that would be the scenario where it helps (provided that you have
a smart disk or a disk array and an intelligent OS aio implementation).
It would be used to fetch the data pages pointed at from an index leaf,
or
Not sure who cares, so xzilla indicated I should drop a note here. I
just made the xlogdump stuff work for 8.1 (trivial) and fixed a few
other small issues that caused it to not work right both generally
and in our environment.
http://pgfoundry.org/tracker/index.php?
On Fri, Oct 20, 2006 at 10:05:01AM -0400, [EMAIL PROTECTED] wrote:
Only if it can be shown that async I/O actually results in an improvement.
Currently, it's speculation, with the one trial implementation showing
little to no improvement. Support is a big word in the face of this
initial
Theo Schlossnagle [EMAIL PROTECTED] writes:
Is it possible to create tables in fashion that will not write info
to the WAL log -- knowingly and intentionally making them
unrecoverable?
Use temp tables?
Also, it's likely that much of the WAL volume is full-page images.
While you can't
Magnus Hagander [EMAIL PROTECTED] writes:
+ #ifdef WIN32
+ #define _WIN32_WINNT 0x0400
+ #endif
Hmm ... in pg_ctl.c I see
#define _WIN32_WINNT 0x0500
Is there a reason for these to be different? Are there other places
that will need this (ie, maybe it should be in c.h instead?)
On Oct 20, 2006, at 1:58 PM, Tom Lane wrote:
Theo Schlossnagle [EMAIL PROTECTED] writes:
Is it possible to create tables in fashion that will not write info
to the WAL log -- knowingly and intentionally making them
unrecoverable?
Use temp tables?
temp tables won't work too well -- unless
+ #ifdef WIN32
+ #define _WIN32_WINNT 0x0400
+ #endif
Hmm ... in pg_ctl.c I see
#define _WIN32_WINNT 0x0500
Is there a reason for these to be different? Are there other
places that will need this (ie, maybe it should be in c.h instead?)
Not really. The default appears to be
On Fri, Oct 20, 2006 at 10:05:01AM -0400, [EMAIL PROTECTED] wrote:
One would need to consider the PostgreSQL architecture, determine where
the bottleneck actually is, and understand why it is a bottleneck fully,
before one could decide how to fix it. So, what is the bottleneck?
I think Mark's
On 10/20/06, Tom Lane [EMAIL PROTECTED] wrote:
So far I've seen no evidence that async I/O would help us, only a lot
of wishful thinking.
is this thread moot? while researching this thread I came across this
article: http://kerneltrap.org/node/6642 describing claims of 30%
performance boost
On Fri, Oct 20, 2006 at 03:04:55PM -0400, Merlin Moncure wrote:
On 10/20/06, Tom Lane [EMAIL PROTECTED] wrote:
So far I've seen no evidence that async I/O would help us, only a lot
of wishful thinking.
is this thread moot? while researching this thread I came across this
article:
Holger Schoenen writes:
ERROR: invalid byte sequence for encoding UTF8: 0xe46973
Command was: --
[...]
-- Started on 2006-09-15 14:56:51 Westeuropäische Normalzeit
The same problem was recently reported on the pgsql-de-allgemein list.
Would just avoiding %Z in Win32's strftime be an
On Fri, 2006-10-20 at 12:27 -0400, Tom Lane wrote:
This was a direct port from a big fat table. I agree, I'm not
convinced that
the partial indexes will buy me much, but this box is so IO bound
that the
planner overhead my just offset the needing to IO bigger indexes.
Well, you
Hi,
On Fri, 2006-10-20 at 10:25 -0400, Tom Lane wrote:
Egad. What an ugly, unmaintainable crock.
I want to second this. I would not make this in RPM spec file.
What about changing
localedir='${prefix}/share/locale'
line (in configure) to
Tom Lane wrote:
Egad. What an ugly, unmaintainable crock.
There is one major PostgreSQL release per year, so even the time
thinking about an alternative solution is longer than just taking the
existing solution.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Fri, 2006-10-20 at 11:50 +0200, Andreas Pflug wrote:
Having pg_dump not saving the function definitions is an intended
behaviour.
The manual defines the pg_catalog schema as containing the system
tables and all the built-in data types, functions, and
operators (section 5.7.5). adminpack is
On Fri, 2006-10-20 at 05:52 +0100, Dave Page wrote:
The adminpack was originally written and intended to become builtin
functions
This is not unique to adminpack: several contrib modules might
eventually become (or have already become) builtins, but adminpack is
the only module that defines
Devrim GUNDUZ wrote:
localedir='${prefix}/share/locale/pgsql/$PGMAJORVERSION'
It's probably better not to create nonstandard directories
below /usr/share/locale, because that's not your directory. If you
want to go with nonstandard paths, create one
in /usr/share/postgresql/.
--
Peter
On Fri, 2006-10-20 at 13:18 -0400, Theo Schlossnagle wrote:
Not sure who cares, so xzilla indicated I should drop a note here. I
just made the xlogdump stuff work for 8.1 (trivial) and fixed a few
other small issues that caused it to not work right both generally
and in our environment.
Neil Conway wrote:
Why does adminpack install functions into pg_catalog? This is
inconsistent with the rest of the contrib/ packages, not to mention
the definition of pg_catalog itself (which ought to hold builtin
object definitions).
Nothing except initdb should add objects in pg_catalog.
On Oct 20, 2006, at 4:24 PM, Simon Riggs wrote:
On Fri, 2006-10-20 at 13:18 -0400, Theo Schlossnagle wrote:
Not sure who cares, so xzilla indicated I should drop a note here. I
just made the xlogdump stuff work for 8.1 (trivial) and fixed a few
other small issues that caused it to not work
Neil Conway wrote:
On Fri, 2006-10-20 at 05:52 +0100, Dave Page wrote:
The adminpack was originally written and intended to become builtin
functions
This is not unique to adminpack: several contrib modules might
eventually become (or have already become) builtins, but adminpack is
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Where are we on releasing beta2 or perhaps going right to an RC1
release? Seems it is time for one of them.
I think we need a beta2 now, and perhaps RC1 in a week. We've done
enough portability hacking recently that some more beta
On Fri, 20 Oct 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
select rowval from myrowtypetable ORDER BY ROW((rowval).*) USING ;
ERROR: operator does not exist: record record
This isn't required by the spec, and it's not implemented. I don't
see that it'd give any new
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think we need a beta2 now, and perhaps RC1 in a week. We've done
enough portability hacking recently that some more beta seems indicated.
OK, what steps do we need to do to get beta2 out?
I think all we really gotta do is update the
Jeremy Drake [EMAIL PROTECTED] writes:
I just think it is quite unexpected that the operator is defined in some
places and not in others.
Row-wise comparison isn't an operator, it's a syntactic construct.
Consider
(now(), 'foo', 42) (SELECT timestampcol, textcol, intcol FROM sometable WHERE
Hi everybody,I have started to work on a project that will be implemented on top of Postgresql. Therefore, I have to warm up with postgresql's internals. I downloaded the source code and currently looking at it. But I have some questions?1. How can I prepare my own query plan? (I will need this
Hi .*Is there any chance to see the quota implementation described in this post in any next releases?http://archives.postgresql.org/pgsql-hackers/2004-07/msg00392.php
Thanks you!Nick
On 10/21/06, Martijn van Oosterhout kleptog@svana.org wrote:
On Fri, Oct 20, 2006 at 03:04:55PM -0400, Merlin Moncure wrote:
On 10/20/06, Tom Lane [EMAIL PROTECTED] wrote:
So far I've seen no evidence that async I/O would help us, only a lot
of wishful thinking.
is this thread moot? while
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
Nothing except initdb should add objects in pg_catalog. AFAICS,
adminpack doesn't have any special requirements, so it should behave
like all other contrib modules.
Okay. Are there any opinions on whether we should make this change
On Fri, 2006-10-20 at 16:05 -0700, dakotali kasap wrote:
1. How can I prepare my own query plan?
You can't: there is currently no public API for constructing plans by
hand. You could kludge something up by hand, but it would be pretty
fragile (internal planner data structures may well change
from my understanding, postgres first needs to partition the tables.
ExecHashTableCreate() is the function that partitions the tables right?
Martijn van Oosterhout wrote:
On Sun, Oct 15, 2006 at 11:08:18PM -0400, HS wrote:
Hello there
I am trying to play around with the hashjoin algorithm in
Magnus Hagander [EMAIL PROTECTED] writes:
+ #ifdef WIN32
+ #define _WIN32_WINNT 0x0400
+ #endif
Hmm ... in pg_ctl.c I see
#define _WIN32_WINNT 0x0500
Is there a reason for these to be different? Are there other
places that will need this (ie, maybe it should be in c.h instead?)
Neil Conway [EMAIL PROTECTED] writes:
On Fri, 2006-10-20 at 22:59 +0200, Peter Eisentraut wrote:
Nothing except initdb should add objects in pg_catalog. AFAICS,
adminpack doesn't have any special requirements, so it should behave
like all other contrib modules.
Okay. Are there any
63 matches
Mail list logo
