The Google Summer of Code web page lists as possible project
ECPG Enhancments: Enable ECPG to generate calls directly for libpq
rather than calls to its own libraries.
What would be the point of that?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Hannu Krosing wrote:
Ühel kenal päeval, K, 2007-03-14 kell 10:22, kirjutas Heikki
Linnakangas:
Clustered indexes have roughly the same performance effect and use cases
as clustered indexes on MS SQL Server, and Index-Organized-Tables on
Oracle, but the way I've implemented them is
Alvaro Herrera wrote:
Which is why we don't do things that way. The code must fit within the
general architecture before application -- particularly if it's an
internal API change. That's what the review process is for.
Yes, of course. As I've said, I have the time to work on this, but I
Hi folks
I am trying to make CLUSTER command just a bit verbose,as an option
here. Added bits to gram.y that should support CLUSTER [VERBOSE] ...
but psql doesn't seem to pick it up.
Where else do I need to update it, besides gram.y, cluster.c and of
course adding new field to ClusterStmt.
Heikki Linnakangas wrote:
One potential issue I'm seeing is that if we rely on the unbroken chain
starting from OldestXmin, and that tuple isn't there because of a bug,
for example, the later version of the tuple is skipped and the row is lost.
After further thought, I don't feel comfortable
Grzegorz Jaskiewicz wrote:
I am trying to make CLUSTER command just a bit verbose,as an option
here. Added bits to gram.y that should support CLUSTER [VERBOSE] ... but
psql doesn't seem to pick it up.
psql? There's some code to detect commands that can't be run in a
transaction block in
Joshua D. Drake wrote:
This is what I suggest.
Provide a tarball of -head with the patch applied.
Here you are:
http://community.enterprisedb.com/git/pgsql-git-20070315.tar.gz
Provide a couple of use cases that can be run with explanation of how to
verify the use cases.
There's a number
On Mar 15, 2007, at 11:36 AM, Heikki Linnakangas wrote:
Grzegorz Jaskiewicz wrote:
I am trying to make CLUSTER command just a bit verbose,as an
option here. Added bits to gram.y that should support CLUSTER
[VERBOSE] ... but psql doesn't seem to pick it up.
psql? There's some code to
Hi,
psql? There's some code to detect commands that can't be run in a
transaction block in src/bin/psql/common.c, maybe that's what you're
looking for.
Or did you mean something else? How doesn't it pick it up?
I think he probably meant that he was getting a syntax error, even after
On Mar 15, 2007, at 11:46 AM, NikhilS wrote:
Grzegorz, I would have suggested to make an entry for VERBOSE in
parser/keywords.c, but it already seems to contain an entry for
VERBOSE. I hope you are using the opt_verbose rule in your gram.y
in the CLUSTER [VERBOSE] case.
sure I am. My
Grzegorz Jaskiewicz wrote:
meaning that if I type in CLUSTER VERBOSE in psql, I get syntax
error.
Your patch works perfectly fine for me.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 2: Don't 'kill
On Mar 15, 2007, at 12:26 PM, Peter Eisentraut wrote:
Your patch works perfectly fine for me.
Ok, I'll try make distclean/make -j2/sudo make install, reboot and
will see.
I was kinda beliving that remaking whole thing from scratch over and
over again wouldn't be a necessity here.
Grzegorz Jaskiewicz [EMAIL PROTECTED] writes:
On Mar 15, 2007, at 12:26 PM, Peter Eisentraut wrote:
Your patch works perfectly fine for me.
Ok, I'll try make distclean/make -j2/sudo make install, reboot and will see.
I was kinda beliving that remaking whole thing from scratch over and over
ok, it works okay.
Thanks.
I am really serious about adding this patch. I would like it to not
only show which tables/indices are being clustered, but also some
sort of progress information (print procentage of job being done, etc).
Any hints, as on what might be useful for others. Perhaps
Hi folks,
I figure - I should start brand new thread for this one - so here you
go.
I am in a need for verbose CLUSTER. Ie. one that would give me
feedback and progress.
Because CLUSTER is divided into two major operations, (data
reordering, index rebuild) - I see it this way:
CLUSTER
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Is there a better way than going to time_t and back?
Isn't the standard SQL-level locution
timestamptz + numeric_value * '1 second'::interval
? I'm not sure what would be the most convenient realization
of this at the C
On Mar 15, 2007, at 5:58 AM, Tom Lane wrote:
? I'm not sure what would be the most convenient realization
of this at the C level, but please stay away from time_t ...
what's wrong with time_t ? Does postgres has some sort of time API,
that can be used instead?
--
Grzegorz Jaskiewicz
Hi!
I'd like to add the ability to show global counters of a couple of
things currently available in pg_stat_all_tables (for example number of
rows added etc) in a global counter for the entire cluster, for
monitoring of an entire cluster without having to connect to each
individual database.
If you read the autovacuum_naptime into an Interval object once, why can't
you just use timestamptz_pl_interval ? You won't be using the interval
input/output repeatedly surely.
Regards
Sailesh
--
Sailesh Krishnamurthy
Amalgamated Insight
[W] (650) 242-3503
[C] (650) 804-6585
-Original
On Wed, 14 Mar 2007, David Fetter wrote:
On Tue, Mar 13, 2007 at 05:54:34PM +, Richard Huxton wrote:
David Fetter wrote:
On Tue, Mar 13, 2007 at 02:21:37PM +, Richard Huxton wrote:
David Fetter wrote:
On Tue, Mar 13, 2007 at 09:31:45AM +, Richard Huxton wrote:
* Another good
David Fetter wrote:
On Wed, Mar 14, 2007 at 12:07:45PM +1300, Edward Stanley wrote:
On Wed, 14 Mar 2007, David Fetter wrote:
On Tue, Mar 13, 2007 at 05:54:34PM +, Richard Huxton wrote:
David Fetter wrote:
On Tue, Mar 13, 2007 at 02:21:37PM +, Richard Huxton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
Gaetano Mendola [EMAIL PROTECTED] writes:
I can immagine a case when a lower module exports a view to upper layer
stating
the interface as list of fields:
first_name, last_name,
with an *hidden* field that is a function
On Wednesday 2007-03-14 08:26, Csaba Nagy wrote:
On Wed, 2007-03-14 at 16:08, [EMAIL PROTECTED] wrote:
On Wed, Mar 14, 2007 at 02:28:03PM +, Gregory Stark wrote:
David Fetter [EMAIL PROTECTED] writes:
CREATE TABLE symptom (
symptom_id SERIAL PRIMARY KEY, /* See above. */
Magnus Hagander wrote:
Hi!
I'd like to add the ability to show global counters of a couple of
things currently available in pg_stat_all_tables (for example number of
rows added etc) in a global counter for the entire cluster, for
monitoring of an entire cluster without having to connect to
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'm thinking of keeping an in-memory mapping of old and new tids of
updated tuples while clustering, instead. That means that cluster
requires a little bit of memory for each RECENTLY_DEAD updated tuple. In
the worst case that means that you run
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
SM [EMAIL PROTECTED] writes:
I got a backend crash in Postgresql 8.2.3 with the plpgsql function.
The following statement in psql causes a signal 11:
psql=# create function testpl() returns void as 'begin return;
end;'language
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NikhilS wrote:
I have tried some update-subselect variations and they seem to work. For
example the case in the src/test/regress/sql/update.sql, which used to
fail till now, seems to work:
UPDATE update_test SET (a,b) = (select a,b FROM
On Thu, Mar 15, 2007 at 10:25:57AM -0400, Alvaro Herrera wrote:
Magnus Hagander wrote:
Hi!
I'd like to add the ability to show global counters of a couple of
things currently available in pg_stat_all_tables (for example number of
rows added etc) in a global counter for the entire
Grzegorz Jaskiewicz wrote:
On Mar 15, 2007, at 5:58 AM, Tom Lane wrote:
? I'm not sure what would be the most convenient realization
of this at the C level, but please stay away from time_t ...
what's wrong with time_t ? Does postgres has some sort of time API,
that can be used
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I'm thinking of keeping an in-memory mapping of old and new tids of
updated tuples while clustering, instead. That means that cluster
requires a little bit of memory for each RECENTLY_DEAD updated tuple. In
the worst case that means
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
This is what I suggest.
Provide a tarball of -head with the patch applied.
Here you are:
http://community.enterprisedb.com/git/pgsql-git-20070315.tar.gz
Provide a couple of use cases that can be run with explanation of how to
verify
Josh Berkus wrote:
And then what? dynamically construct all your SQL queries?
Sure, sounds like a simple solution to me...
Not to mention DB security issues. How do you secure your database when
your web client has DDL access?
So, Edward, the really *interesting* idea would be to come
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Mar 15, 2007 at 08:31:24AM -0700, Ron Mayer wrote:
Josh Berkus wrote:
And then what? dynamically construct all your SQL queries?
Sure, sounds like a simple solution to me...
Not to mention DB security issues. How do you secure your
On Mar 15, 2007, at 11:31 , Ron Mayer wrote:
Josh Berkus wrote:
And then what? dynamically construct all your SQL queries?
Sure, sounds like a simple solution to me...
Not to mention DB security issues. How do you secure your
database when
your web client has DDL access?
So, Edward,
Last try there was a fight about syntax of introduced commands. And we (Oleg and
me) developed variant of patch with another syntax. We will not change docs
until agreement will be reached, current version
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/
Following demonstrates subset of FTS
Ron Mayer [EMAIL PROTECTED] writes:
I have a system with many essentially user-defined fields, and was
thinking of creating something similar to an Array type and writing
some GIST indexes for it.
My current workaround is to store them as a YAML document and use
tsearch to index it (with
On Thu, 2007-03-15 at 17:01, A.M. wrote:
It seems to me that postgresql is especially well-suited to run DDL
at runtime, so what's the issue?
The issue is that some applications are not well suited to run DDL at
runtime :-)
As I already mentioned in another post in this thread, our
Gregory Stark wrote:
Ron Mayer [EMAIL PROTECTED] writes:
I have a system with many essentially user-defined fields, and was
thinking of creating something similar to an Array type and writing
some GIST indexes for it.
My current workaround is to store them as a YAML document and use
While fooling with getting SPI to use the plancache, I got annoyed again
about how SPI_prepare() and related functions refer to SPI plan pointers
as void *. I'm all for having the structure be opaque to callers, but
to me void * means any old pointer, which this surely is not. I'd
like to change
On 3/15/07, Grzegorz Jaskiewicz [EMAIL PROTECTED] wrote:
I figure - I should start brand new thread for this one - so here you
go.
I am in a need for verbose CLUSTER. Ie. one that would give me
feedback and progress.
Because CLUSTER is divided into two major operations, (data
reordering, index
So I just updated my x86_64 machine to Fedora Core 6, and I find that
rebuilding our CVS HEAD gives a batch of noise that was not there
before:
/usr/bin/ld: skipping incompatible /usr/lib/libtcl8.4.so when searching for
-ltcl8.4
/usr/bin/ld: skipping incompatible /usr/lib/libdl.so when searching
Gaetano Mendola [EMAIL PROTECTED] writes:
NikhilS wrote:
I have tried some update-subselect variations and they seem to work. For
example the case in the src/test/regress/sql/update.sql, which used to
fail till now, seems to work:
UPDATE update_test SET (a,b) = (select a,b FROM update_test
On Thursday 15 March 2007 12:17, Teodor Sigaev wrote:
Last try there was a fight about syntax of introduced commands. And we
(Oleg and me) developed variant of patch with another syntax. We will not
change docs until agreement will be reached, current version
And is there some another objections?
Most people whom I talk to about tsearch who want the syntax changed to make
it easier want something akin to just CREATE INDEX fti1 on t1(c1) USING
FULLTEXT and then be done with it. This patch isn't going to give people
that.
+1 (again)
Joshua D. Drake [EMAIL PROTECTED] writes:
+1 (again) Although I would see something like this:
CREATE INDEX fti1 on t1(c1) USING FULLTEXT [WITH] GIST | GIN
Surely the CREATE INDEX syntax has got enough warts on it already.
Can't we express this as a particular operator class, or something
that
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
+1 (again) Although I would see something like this:
CREATE INDEX fti1 on t1(c1) USING FULLTEXT [WITH] GIST | GIN
Surely the CREATE INDEX syntax has got enough warts on it already.
Can't we express this as a particular operator
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
Surely the CREATE INDEX syntax has got enough warts on it already.
Do you mean something like:
CREATE INDEX ftil ON t1 USING GIST|GIN(C1 FULLTEXT);
Where FULLTEXT is like VARCHAR OPS?
Yeah, that one. It might be more consistent to
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
Surely the CREATE INDEX syntax has got enough warts on it already.
Do you mean something like:
CREATE INDEX ftil ON t1 USING GIST|GIN(C1 FULLTEXT);
Where FULLTEXT is like VARCHAR OPS?
Yeah, that one. It might be
On Thu, 15 Mar 2007, Robert Treat wrote:
On Thursday 15 March 2007 12:17, Teodor Sigaev wrote:
Last try there was a fight about syntax of introduced commands. And we
(Oleg and me) developed variant of patch with another syntax. We will not
change docs until agreement will be reached, current
On Thu, 15 Mar 2007, Joshua D. Drake wrote:
And is there some another objections?
Most people whom I talk to about tsearch who want the syntax changed to make
it easier want something akin to just CREATE INDEX fti1 on t1(c1) USING
FULLTEXT and then be done with it. This patch isn't going
Peter,
The Google Summer of Code web page lists as possible project
ECPG Enhancments: Enable ECPG to generate calls directly for libpq
rather than calls to its own libraries.
What would be the point of that?
More importantly, Michael hasn't volunteered to mentor this year, so I think
we
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Mar 15, 2007 at 12:49:10PM -0400, Andrew Dunstan wrote:
Gregory Stark wrote:
Ron Mayer [EMAIL PROTECTED] writes:
I have a system with many essentially user-defined fields, and was
thinking of creating something similar to an Array
Most people whom I talk to about tsearch who want the syntax changed to make
it easier want something akin to just CREATE INDEX fti1 on t1(c1) USING
FULLTEXT and then be done with it. This patch isn't going to give people
that.
Since we use standard postgresql-ish CREATE INDEX command,
53 matches
Mail list logo
