On 1/24/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
I have just counted the number of read/write calls on the CLOG blocks.
As
you can
see the total number of CLOG reads jumped from 545323 to 1181851 i.e.
1181851 - 545323 = 636528 CLOG block reads for 1554697 pages
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think the proper fix is probably to establish a new eval_context
when we enter an EXCEPTION block, and destroy it again on the way out.
Slightly annoying, but probably small next to the other overhead of
a
Good memory you have and you exactly right.
Yes... the replication is using posgres's normal transactions ie 2 phase
commits and it works like a dream.
When moving data during replication, the locks are happening at record
level, and its intrinsic to the postgres transaction machinery.
ie
On Wed, 24 Jan 2007 22:27:10 +0100, Peter Eisentraut [EMAIL PROTECTED] wrote:
I wrote:
The closest I could find is Oracle Text, the full-text search for
Oracle.
Oh, and note that Oracle Text is an extension and not included in the
Oracle database product proper.
Same with DB2 NSE,
Pavan Deolasee wrote:
On 1/24/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Hmm. So there is some activity there. Could you modify the patch to
count how many of those reads came from OS cache? I'm thinking of doing
a gettimeofday() call before and after read, and counting how many
calls
Jim C. Nasby wrote:
On Thu, Jan 25, 2007 at 12:52:02AM -0300, Alvaro Herrera wrote:
Jim C. Nasby wrote:
I'll generally start with a cost delay of 20ms and adjust based on IO
utilization.
I've been considering set a default autovacuum cost delay to 10ms; does
this sound reasonable?
The
Hm, having skimmed through the Evgen Potemkin's recursive queries patch I find
it quite different from what I was expecting. My own thinking was headed off
in a different direction.
Basically the existing patch reimplements a new kind of join which implements
a kind of nested loop join (with
On 1/24/07, Andrew Dunstan [EMAIL PROTECTED] wrote:
Peter Eisentraut wrote:
contrib is a horrible misnomer. Can we maybe bite the bullet and call
it something else?
plugins?
How about 'modules' or 'extras' or 'extensions'? :)
standard-plugins might be more informative. I think of them as
On 1/25/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
Also is it worth optimizing on the total read() system calls which might
not
cause physical I/O, but
still consume CPU ?
I don't think it's worth it, but now that we're talking about it: What
I'd like to do to
Ühel kenal päeval, N, 2007-01-25 kell 11:08, kirjutas Gregory Stark:
Hm, having skimmed through the Evgen Potemkin's recursive queries patch I find
it quite different from what I was expecting. My own thinking was headed off
in a different direction.
Basically the existing patch reimplements
Pavan Deolasee wrote:
Another simpler solution for VACUUM would be to read the entire CLOG file
in local memory. Most of the transaction status queries can be satisfied
from
this local copy and the normal CLOG is consulted only when the status is
unknown (TRANSACTION_STATUS_IN_PROGRESS)
The
Dawid Kuroczko wrote:
This is the reason I like 'modules' best. It makes one think that it
is something maybe part of core, maybe not, but it has been isolated
into separate entity for maintenance reasons.
On etymological grounds, modules would also be my favorite, but the
term module is
Hi,
Alvaro Herrera wrote:
1. There will be two kinds of processes, autovacuum launcher and
autovacuum worker.
Sounds similar to what I do in Postgres-R: one replication manager and
several replication workers. Those are called remote backends (which
is somewhat of an unfortunate name, IMO.)
On Thu, Jan 25, 2007 at 11:08:14AM +, Gregory Stark wrote:
b) I do want to be able to support depth-first searching too. I'm not sure how
to reconcile that with the repeated-join conceptual model. We could always
resort the entire result set after generating it but that seems like an
I'm looking over the VC build trying to eliminate what warnings are
left. One thing that appears in a couple of places is stuff like:
.\src\bin\psql\print.c(2014): warning C4090: 'function' : different
'const' qualifiers
This happens in psql when we do free() on a variable that's const char
**.
Looking at the VC warnings, I find that in ECPGDynamicType()
(typename.c in ecpglib), the default branch of the case statement
returns -type. But the function returns unsigned int, so returning a
negative value seems very strange to me.
At least it throws a warning in VC++.
//Magnus
Magnus Hagander wrote:
I'm looking over the VC build trying to eliminate what warnings are
left. One thing that appears in a couple of places is stuff like:
.\src\bin\psql\print.c(2014): warning C4090: 'function' : different
'const' qualifiers
This happens in psql when we do free() on a
Peter Eisentraut [EMAIL PROTECTED] writes:
The code in question is:
const char **headers;
[...]
free(headers);
Perhaps it ought not be declared const char **headers if you're planning on
freeing it? I mean, it's not like you can pass an actual pointer to constant
memory to
On Thu, Jan 25, 2007 at 01:38:14PM +0100, Peter Eisentraut wrote:
Magnus Hagander wrote:
I'm looking over the VC build trying to eliminate what warnings are
left. One thing that appears in a couple of places is stuff like:
.\src\bin\psql\print.c(2014): warning C4090: 'function' :
Magnus Hagander [EMAIL PROTECTED] writes:
I won't claim to know the inners good enough to comment on it. Does
const char ** really mean that the point is const, or the pointer that
it points to is const?
const char ** means the character at the end of the pointer chain is
constant. Which
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Jan 25, 2007 at 11:08:14AM +, Gregory Stark wrote:
b) I do want to be able to support depth-first searching too. I'm not sure
how
to reconcile that with the repeated-join conceptual model. We could always
resort the entire result
On Thu, 25 Jan 2007, Magnus Hagander wrote:
I'm looking over the VC build trying to eliminate what warnings are
left. One thing that appears in a couple of places is stuff like:
.\src\bin\psql\print.c(2014): warning C4090: 'function' : different
'const' qualifiers
Seems like other projects
On Fri, Jan 26, 2007 at 12:26:45AM +1100, Gavin Sherry wrote:
On Thu, 25 Jan 2007, Magnus Hagander wrote:
I'm looking over the VC build trying to eliminate what warnings are
left. One thing that appears in a couple of places is stuff like:
.\src\bin\psql\print.c(2014): warning C4090:
On Thu, Jan 25, 2007 at 01:20:10PM +, Gregory Stark wrote:
const char ** means the character at the end of the pointer chain is
constant. Which means my previous message is misguided, ignore it, sorry. In
short, yes, this is a limitation of the const syntax in C and you have to cast
it
Current WAL Header uses 32 bytes on a 64-bit CPU. It seems possible to
reduce this to 24 bytes, without reducing resilience, when
full_page_writes = off. This will reduce overall WAL volumes by around
5-15%, depending upon the application with performance gains in various
ways.
If
Simon Riggs wrote:
Current WAL Header uses 32 bytes on a 64-bit CPU. It seems possible to
reduce this to 24 bytes, without reducing resilience, when
full_page_writes = off. This will reduce overall WAL volumes by around
5-15%, depending upon the application with performance gains in various
Gavin Sherry wrote:
On Thu, 25 Jan 2007, Magnus Hagander wrote:
I'm looking over the VC build trying to eliminate what warnings are
left. One thing that appears in a couple of places is stuff like:
.\src\bin\psql\print.c(2014): warning C4090: 'function' : different
'const' qualifiers
[
Sorry if this is a duplicate -- resending since it hasn't made it to the
list after 1 1/2 hour, possibly due to large attachment (?); here's a
URL instead:
http://www.joeconway.com/das_data_load_failure2.sql.gz
]
We just came upon a crash bug in Postgres = 8.2. The attached
standalone
Thanks, I've heard that, but in this case won't exactly fit my needs...
..First, I'm working on a PostgreSQL 8.1.4 modification, and it
would be really difficult to add all the changes I've made to the
new version.
...Second, I need to do all this form the backend (Postgres
Source Code). I
Discussion tsearch in core patch, for inclusion shows
(http://archives.postgresql.org/pgsql-hackers/2007-01/msg01165.php and
following http://archives.postgresql.org/pgsql-hackers/2007-01/msg01186.php)
that there are some problems with contrib promotion and expansion.
I've encountered with bad
On Thu, 2007-01-25 at 14:04 +, Heikki Linnakangas wrote:
Simon Riggs wrote:
Current WAL Header uses 32 bytes on a 64-bit CPU. It seems possible to
reduce this to 24 bytes, without reducing resilience, when
full_page_writes = off. This will reduce overall WAL volumes by around
5-15%,
Joe Conway [EMAIL PROTECTED] writes:
psql:/home/jconway/pgsql/das_data_load_failure2.sql:419: PANIC: failed
to add item to the left sibling for pk_status_log_2007_01_4_10
Was this preceded by a WARNING?
Was the server running with a log_min_messages low enough to log WARNINGs?
I probably
Gregory Stark wrote:
Joe Conway [EMAIL PROTECTED] writes:
psql:/home/jconway/pgsql/das_data_load_failure2.sql:419: PANIC: failed
to add item to the left sibling for pk_status_log_2007_01_4_10
Was this preceded by a WARNING?
Was the server running with a log_min_messages low enough to log
Stefan Kaltenbrunner wrote:
Gregory Stark wrote:
Joe Conway [EMAIL PROTECTED] writes:
psql:/home/jconway/pgsql/das_data_load_failure2.sql:419: PANIC: failed
to add item to the left sibling for pk_status_log_2007_01_4_10
Was this preceded by a WARNING?
Was the server running with a
Joe Conway wrote:
We just came upon a crash bug in Postgres = 8.2. The attached
standalone script (just needs a database with plpgsql installed)
reproduces the crash for me on 32-bit machines (i686) but NOT on 64 bit
machines (x86_64), for Postgres 8.2 and cvs-head, but not on 8.1. We've
Folks,
At this moment the following is the list of the unused OIDs. For the
uuid datatype I use a script for generating catalog entries. I can close
some gaps there if the masters are okay with this. Are any OIDs
reserved for later or any range can be used in this case?
2 - 9
32
86 - 88
90
100
Nikolay Samokhvalov wrote:
1. Change default behaviour of MODULE_NAME.sql file so it will be
installed in MODULE_NAME schema instead of public (e.g., hstore
schema will contain all hstore relations and functions).
That might be a good idea in any case.
2. Allow running configure with
uuid datatype I use a script for generating catalog entries. I can close
some gaps there if the masters are okay with this. Are any OIDs
reserved for later or any range can be used in this case?
IMHO, better way is to use some high oids ( for example, starting from 8000 )
and before
Gregory Stark wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Jan 25, 2007 at 11:08:14AM +, Gregory Stark wrote:
b) I do want to be able to support depth-first searching too. I'm not sure
how
to reconcile that with the repeated-join conceptual model. We could always
Heikki Linnakangas wrote:
Joe Conway wrote:
We just came upon a crash bug in Postgres = 8.2. The attached
standalone script (just needs a database with plpgsql installed)
reproduces the crash for me on 32-bit machines (i686) but NOT on 64 bit
machines (x86_64), for Postgres 8.2 and cvs-head,
Alvaro Herrera wrote:
Jim C. Nasby wrote:
I'll generally start with a cost delay of 20ms and adjust based on IO
utilization.
I've been considering set a default autovacuum cost delay to 10ms; does
this sound reasonable?
It really depends on the system. Most of our systems run anywhere
On Thu, Jan 25, 2007 at 10:45:43AM -0400, Luis D. García wrote:
Well, maybe I didn't make myself clear, this is what I need to do:
I need to know the values of some fields (columns) from the last
inserted tuple. The problem is that I need to do this in the moment
I'm inserting a new one (all
Heikki Linnakangas [EMAIL PROTECTED] writes:
ISTM that we would get the effect your looking for by just moving the
xl_tot_len field to the end, and only storing it for records with backup
blocks:
I like that formulation better --- seems like less
change-for-the-sake-of-change.
This is a fairly large patch and I would like the chance to review it
before it goes in --- we'll commit tomorrow is not exactly a decent
review window.
Not a problem.
One possible argument for this over the contrib version is a saner
approach to dumping and restoring configurations. However,
Heikki Linnakangas wrote:
Heikki Linnakangas wrote:
Joe Conway wrote:
We just came upon a crash bug in Postgres = 8.2. The attached
standalone script (just needs a database with plpgsql installed)
reproduces the crash for me on 32-bit machines (i686) but NOT on 64 bit
machines (x86_64), for
Heikki Linnakangas [EMAIL PROTECTED] writes:
Hmm. There seems to be something wrong in the free space calculation in
the algorithm for choosing the right split location. I'll dig deeper,
unless someone beats me to it..
I seem to recall that that part of the code was changed recently, so you
the patch. I'm personally not sold on the need for modifications to the
SQL grammar, for example, as opposed to just using a set of SQL-callable
functions and some new system catalogs.
SQL grammar isn't changed significantly - just add variants of CREATE/DROP/ALTER
/COMMENTS commands. Next,
Gevik Babakhani [EMAIL PROTECTED] writes:
At this moment the following is the list of the unused OIDs. For the
uuid datatype I use a script for generating catalog entries. I can close
some gaps there if the masters are okay with this. Are any OIDs
reserved for later or any range can be used in
Nikolay Samokhvalov [EMAIL PROTECTED] writes:
1. Change default behaviour of MODULE_NAME.sql file so it will be
installed in MODULE_NAME schema instead of public (e.g., hstore
schema will contain all hstore relations and functions).
This might be a good idea, but it's hardly transparent; it
On Thu, Jan 25, 2007 at 07:52:50PM +0900, Galy Lee wrote:
It is very hard for any normal user to set this correctly. I think the
experience / trial-and-error approach is awful for the user, every DBA
need to be an expert of vacuum to keep the system stable. For vacuum is
still a big threat
Teodor Sigaev wrote:
the patch. I'm personally not sold on the need for modifications to the
SQL grammar, for example, as opposed to just using a set of SQL-callable
functions and some new system catalogs.
SQL grammar isn't changed significantly - just add variants of
CREATE/DROP/ALTER
On Thu, Jan 25, 2007 at 08:04:49AM -0800, Joshua D. Drake wrote:
It really depends on the system. Most of our systems run anywhere from
10-25ms. I find that any more than that, Vacuum takes too long.
How do you measure the impact of setting it to 12 as opposed to 15?
On 1/25/07, Teodor Sigaev [EMAIL PROTECTED] wrote:
It's should clear enough for now - dump data from old db and load into new one.
But dump should be without any contrib/tsearch2 related functions.
Upgrading from 8.1.x to 8.2.x was not tivial because of very trivial
change in API (actually not
On Thu, Jan 25, 2007 at 01:23:57PM +0100, Magnus Hagander wrote:
Looking at the VC warnings, I find that in ECPGDynamicType()
(typename.c in ecpglib), the default branch of the case statement
returns -type. But the function returns unsigned int, so returning a
negative value seems very strange
On Thu, 2007-01-25 at 11:03 -0500, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
ISTM that we would get the effect your looking for by just moving the
xl_tot_len field to the end, and only storing it for records with backup
blocks:
I like that formulation better ---
though that we still have the more odd grammar of actually using Tsearch
to query. Although I don't really have a better suggestion without
adding some ungodly obscure operator.
IMHO, best possible solution is 'WHERE table.text_field @ text'.
Operator @ internally makes equivalent of
The problem with this proposal is that the ISPs aren't the ones running
configure --- these days, most people are running prebuilt packages
(RPMs or DEBs or what have you). So what you are hoping is that the
packagers will choose to do this and thereby force these modules into
the standard
Joshua D. Drake wrote:
The problem with this proposal is that the ISPs aren't the ones running
configure --- these days, most people are running prebuilt packages
(RPMs or DEBs or what have you). So what you are hoping is that the
packagers will choose to do this and thereby force these modules
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
I would like to see pgcrypto (or at least some of it's functionality) in
core.
I believe the reason we keep it separate is so that people can easily
make crypto-free versions of PG for use in countries where encryption
capability is considered
Joshua D. Drake [EMAIL PROTECTED] writes:
That's basically how the existing patch approached the problem. It invents a
new type of join and a new type of tuplestore that behaves this way. This
has
the advantage of working the way Oracle users expect and being relatively
simple
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Hmm. There seems to be something wrong in the free space calculation in
the algorithm for choosing the right split location. I'll dig deeper,
unless someone beats me to it..
I seem to recall that that part of the code was changed
Well perhaps it is time to trim Contrib even further. E.g;
Why is ltree still in contrib? What prevents it from being in core?
not sure - ltree is quite useful but I'm not convinced it is really core
material
Why?
Why is pgcrypto,pgstattuple and pg_freespacemap in contrib?
I would
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
I would like to see pgcrypto (or at least some of it's functionality) in
core.
I believe the reason we keep it separate is so that people can easily
make crypto-free versions of PG for use in countries where encryption
Heikki Linnakangas [EMAIL PROTECTED] writes:
I think I found it. The page splitting code didn't take into account
that when the new item is the first one on the right page, it also
becomes the high key of the left page.
Good catch! This is something that would not make a difference with
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
I believe the reason we keep it separate is so that people can easily
make crypto-free versions of PG for use in countries where encryption
capability is considered subject to arms regulations. Not sure how
important that case really
You miss the point. Everybody knows that those laws are not too hard
to circumvent if you are willing to break the law. The question is
how hard is it for someone to distribute Postgres into one of those
countries *without* breaking any local law. We won't be making things
better if we
On Thu, 25 Jan 2007, Nikolay Samokhvalov wrote:
On 1/25/07, Teodor Sigaev [EMAIL PROTECTED] wrote:
It's should clear enough for now - dump data from old db and load into new
one.
But dump should be without any contrib/tsearch2 related functions.
Upgrading from 8.1.x to 8.2.x was not tivial
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'm afraid the bug has been there for ages, but the 90%-fillfactor on
rightmost page patch made it much more likely to get triggered.
But that patch has been there for ages too; the only new thing in 8.2 is
that the fillfactor is configurable, but
decibel=# select version();
PostgreSQL 8.3devel on i386-apple-darwin8.8.2, compiled by GCC
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)
decibel=# select box '((0,0),(2,2))' ~ point '(1,1)';
ERROR: operator does not exist: box ~ point
LINE 1: select box
On Thu, 25 Jan 2007, Joshua D. Drake wrote:
The problem with this proposal is that the ISPs aren't the ones running
configure --- these days, most people are running prebuilt packages
(RPMs or DEBs or what have you). So what you are hoping is that the
packagers will choose to do this and
Oleg Bartunov wrote:
On Thu, 25 Jan 2007, Joshua D. Drake wrote:
The problem with this proposal is that the ISPs aren't the ones running
configure --- these days, most people are running prebuilt packages
(RPMs or DEBs or what have you). So what you are hoping is that the
packagers will
Joshua D. Drake wrote:
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
I would like to see pgcrypto (or at least some of it's
functionality) in core.
I believe the reason we keep it separate is so that people can
easily make crypto-free versions of PG for use in
Joshua D. Drake [EMAIL PROTECTED] writes:
Oleg Bartunov wrote:
we have several requests to improve ltree, particularly, people want
to expand class of allowed symbols and configurable separator, which is
hard-coded right now. Also, we discussed GiN support for ltree.
O.k. but how does that
FWIW:
* Better packaging support, eg make it easier to add/remove an extension
module and control how pg_dump deals with it. We talked about that
awhile back but nobody did anything with the ideas.
+1
* Better documentation for the contrib modules; some of them are
reasonably well doc'd
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Oleg Bartunov wrote:
we have several requests to improve ltree, particularly, people want
to expand class of allowed symbols and configurable separator, which is
hard-coded right now. Also, we discussed GiN support for ltree.
O.k.
Joshua D. Drake wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Oleg Bartunov wrote:
we have several requests to improve ltree, particularly, people want
to expand class of allowed symbols and configurable separator, which is
hard-coded right now. Also, we discussed GiN
Why is ltree still in contrib? What prevents it from being in core?
Nothing. But I don't see any advantage of placing it in core - it changes
nothing in SQL, API or feature. Moving tsearch2 into core allows to manage
configuration with nice SQL API, using SysCache, automatical rereading
I don't think two releases from API change to API change is enough -
postgresql is running larger and larger databases by now and I expect
people to upgrade less often in the future (and iirc you already said
something along the lines of recommending such things on occasion to
your customers
Teodor Sigaev wrote:
Why is ltree still in contrib? What prevents it from being in core?
Nothing. But I don't see any advantage of placing it in core - it
changes nothing in SQL, API or feature. Moving tsearch2 into core allows
to manage configuration with nice SQL API, using SysCache,
This might be a good idea, but it's hardly transparent; it can be
counted on to break the applications of just about everyone using those
modules today.
Hmm, can we make separate schema for all contib modules and include it in
default search_path? It will not touchs most users.
--
Teodor
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'm afraid the bug has been there for ages, but the 90%-fillfactor on
rightmost page patch made it much more likely to get triggered.
But that patch has been there for ages too; the only new thing in 8.2 is
that the fillfactor is
Teodor Sigaev wrote:
This might be a good idea, but it's hardly transparent; it can be
counted on to break the applications of just about everyone using those
modules today.
Hmm, can we make separate schema for all contib modules and include it
in default search_path? It will not touchs
Joshua D. Drake wrote:
Teodor Sigaev wrote:
This might be a good idea, but it's hardly transparent; it can be
counted on to break the applications of just about everyone using those
modules today.
Hmm, can we make separate schema for all contib modules and include it
in default
In a thread in July last year, I raised the possibility of transforming
a query to allow functional indexes to be utilised automatically.
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00323.php
This idea can work and has many benefits, but there are some
complexities. I want to
On 1/25/07, Jim C. Nasby [EMAIL PROTECTED] wrote:
decibel=# select version();
PostgreSQL 8.3devel on i386-apple-darwin8.8.2, compiled by GCC
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)
decibel=# select box '((0,0),(2,2))' ~ point '(1,1)';
ERROR: operator does
The author of this bug was good enough to send me a copy, since I don't
normally read the -bugs list. It can now be found at
http://archives.postgresql.org/pgsql-bugs/2007-01/msg00111.php .
I dug into it a bit and found that pltcl and plpython appear to use
almost identical code, but only
On 1/18/2007 10:35 AM, Tom Lane wrote:
[EMAIL PROTECTED] writes:
Many of the keywords listed in keywords.c are defined with symbolic
names that end in '_P' (underscore P).
What differentiates those keywords from the other keywords? What does
the 'P' stand for?
P = Parser. The reason for the
I have had to reverse out this patch because Py_RETURN_TRUE is only
supported in Python versions = 2.3, and we support older versions. I
did add a comment:
* We would like to use Py_RETURN_TRUE and Py_RETURN_FALSE here for
* generating SQL from trigger functions, but those are only
*
Some years ago there was discussion of consistently P-ifying *all* those
macros, but it didn't get done; I think Thomas or somebody objected that
it would make gram.y needlessly harder to read.
Are there many people who read gram.y on a regular base?
I can't seem to put it down :-)
I wrote:
I see that SQL level prepare calls regprocin() to resolve type names,
so maybe we should that for the PLs when calling SPI_prepare as well.
Of course, that should be regtypein()
cheers
andrew
---(end of broadcast)---
TIP 9: In
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momjian) writes:
Fix for plpython functions; return true/false for boolean,
This patch has broken a majority of the buildfarm.
Yea, reverted with comment added.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
Andrew Dunstan [EMAIL PROTECTED] writes:
I see that SQL level prepare calls regprocin() to resolve type names,
so maybe we should that for the PLs when calling SPI_prepare as well.
Of course, that should be regtypein()
[ squint... ] build_regtype_array seems a rather stupid bit of code.
How
Simon Riggs [EMAIL PROTECTED] writes:
A simpler, alternate proposal is to allow the user to specify whether a
functional index is transformable or not using CREATE or ALTER INDEX,
with a default of not transformable. That then leaves the responsibility
for specifying this with the user, who as
Andrew Dunstan [EMAIL PROTECTED] writes:
I dug into it a bit and found that pltcl and plpython appear to use
almost identical code, but only pltcl has this limitation documented.
I'm inclined to say we should document this for plperl and plpython for
stable releases and remove the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I see that SQL level prepare calls regprocin() to resolve type names,
so maybe we should that for the PLs when calling SPI_prepare as well.
Of course, that should be regtypein()
[ squint... ] build_regtype_array seems a
Markus Schiltknecht wrote:
Hi Markus,
Alvaro Herrera wrote:
1. There will be two kinds of processes, autovacuum launcher and
autovacuum worker.
Sounds similar to what I do in Postgres-R: one replication manager and
several replication workers. Those are called remote backends (which
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I dug into it a bit and found that pltcl and plpython appear to use
almost identical code, but only pltcl has this limitation documented.
I'm inclined to say we should document this for plperl and plpython for
stable releases and
Jim C. Nasby wrote:
On Mon, Jan 22, 2007 at 12:17:39PM -0800, Ron Mayer wrote:
Gregory Stark wrote:
Actually no. A while back I did experiments to see how fast reading a file
sequentially was compared to reading the same file sequentially but
skipping
x% of the blocks randomly.
On Thu, Jan 25, 2007 at 01:59:33PM -0500, Merlin Moncure wrote:
On 1/25/07, Jim C. Nasby [EMAIL PROTECTED] wrote:
decibel=# select version();
PostgreSQL 8.3devel on i386-apple-darwin8.8.2, compiled by GCC
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5363)
Is there a TODO here?
---
Heikki Linnakangas wrote:
Pavan Deolasee wrote:
Another simpler solution for VACUUM would be to read the entire CLOG file
in local memory. Most of the transaction status queries can be
1 - 100 of 123 matches
Mail list logo
