2008/7/18 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
Maybe we can use some well defined implicit record, maybe NEW (or
RESULT, ROW_RESULT, ROW, TABLE_ROW, ...) like trigger - some like
That sounds like exactly the sort of kluge-solution that I didn't
want to get
On Fri, Jul 18, 2008 at 10:41:36AM +0530, Gurjeet Singh wrote:
Just started INIT cluster Slonik command and that spiked too.. for more than
10 minutes now!!
Are you attempting to do Slony changes (such as install Slony) on an
active database? I strongly encourage you to read the Slony
On Thu, 2008-07-17 at 16:37 -0700, Dann Corbit wrote:
Large table unique index equality search should be very fast with hashed
index (and the only place where any advantage will be seen). Hashed
indexes are useless for any search besides equality and gain more and
more when the levels of
On 7/18/08, Tom Lane [EMAIL PROTECTED] wrote:
I've been working on the TABLE-function patch, and I am coming to the
conclusion that it's really a bad idea for plpgsql to not associate
variables with output columns --- that is, I think we should make
RETURNS TABLE columns semantically just
David E. Wheeler writes:
On Jul 17, 2008, at 03:45, Michael Paesold wrote:
Wouldn't it be possible to create a variant of regexp_replace, i.e.
regexp_replace(citext,citext,text), which would again lower-case
the first two arguments before passing the input to
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-07-17 at 16:37 -0700, Dann Corbit wrote:
Large table unique index equality search should be very fast with hashed
index (and the only place where any advantage will be seen). Hashed
indexes are useless for any search besides equality and
On Fri, 2008-07-18 at 11:07 +0100, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
hash lookups can in theory be O(1).
I'm not sure whether that applies here? I'm interested in how *this*
patch will work, not in more generic algorithm theory.
To patch authors: Can we please see a
[EMAIL PROTECTED] (Markus Wanner) writes:
as you might know, Postgres-R relies on primary keys to address tuples
of a table. It cannot replicate tables without a primary key.
Slony-I does the same, with the variation that it permits the option
of using a candidate primary key, namely an index
Hello Chris,
chris wrote:
Slony-I does the same, with the variation that it permits the option
of using a candidate primary key, namely an index that is unique+NOT
NULL.
If it is possible to support that broader notion, that might make
addition of these sorts of logic more widely useful.
Gregory Stark escribió:
For cpu-bound databases with small indexes there might be a win if you can
avoid the binary search of all the elements on a page. (Have we modified btree
to do that or does it still scan sequentially on the leaf pages?)
Hmm? It has used binary search since as long as
On Fri, Jul 18, 2008 at 10:15:42AM +0530, Gurjeet Singh wrote:
On Fri, Jul 18, 2008 at 10:05 AM, Gurjeet Singh [EMAIL PROTECTED]
wrote:
On Fri, Jul 18, 2008 at 9:58 AM, Tom Lane [EMAIL PROTECTED] wrote:
Gurjeet Singh [EMAIL PROTECTED] writes:
During these spikes, in the 'top'
On Fri, Jul 18, 2008 at 03:04:08PM +0200, Markus Schiltknecht wrote:
Hello Chris,
chris wrote:
Slony-I does the same, with the variation that it permits the
option of using a candidate primary key, namely an index that is
unique+NOT NULL.
If it is possible to support that broader notion,
Gregory Stark wrote:
For i/o-bound databases with very large indexes there should be an opportunity
where btree lookups are O(logn) and hash lookups can in theory be O(1).
Ignoring the big-O complexity, if a hash index only stores a 32-bit hash
code instead of the whole key, it could be a big
Heikki Linnakangas [EMAIL PROTECTED] writes:
Gregory Stark wrote:
For i/o-bound databases with very large indexes there should be an
opportunity
where btree lookups are O(logn) and hash lookups can in theory be O(1).
Ignoring the big-O complexity, if a hash index only stores a 32-bit hash
On Fri, Jul 18, 2008 at 10:44 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Ignoring the big-O complexity, if a hash index only stores a 32-bit hash
code instead of the whole key, it could be a big win in storage size, and
therefore in cache-efficiency and performance, when the keys are very
Marko Kreen [EMAIL PROTECTED] writes:
On 7/18/08, Tom Lane [EMAIL PROTECTED] wrote:
1. It's ludicrous to argue that standards compliance requires the
behavior-as-submitted. plpgsql is not specified by the SQL standard.
Yes, but it would be a good feature addition to plpgsql.
Currently there
On Fri, Jul 18, 2008 at 10:41:20AM +0900, Tatsuo Ishii wrote:
Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
I tried this patch vs. CVS HEAD used my usual configure option with
only --with-prefix set, then
David Fetter [EMAIL PROTECTED] writes:
On Fri, Jul 18, 2008 at 03:04:08PM +0200, Markus Schiltknecht wrote:
But what do we have primary keys for, in the first place?
We have them because people are used to thinking in terms of a
PRIMARY KEY, not because that concept is actually
On Fri, Jul 18, 2008 at 07:56:09AM -0700, David Fetter wrote:
On Fri, Jul 18, 2008 at 10:41:20AM +0900, Tatsuo Ishii wrote:
Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
I tried this patch vs. CVS HEAD
David Fetter [EMAIL PROTECTED] writes:
On Fri, Jul 18, 2008 at 03:04:08PM +0200, Markus Schiltknecht wrote:
Hello Chris,
chris wrote:
Slony-I does the same, with the variation that it permits the
option of using a candidate primary key, namely an index that is
unique+NOT NULL.
If it is
Hi,
David Fetter wrote:
While I'm a chicken rather than a pig on this project
http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig, I believe that
covering the more general case right from the start would be a much
better plan.
I was trying to say that Postgres-R internally relies only on a
Hi,
sorry, some strange key-combination made my mail client send too early...
I myself wrote:
I was trying to say that Postgres-R internally relies only on a unique
index with not null constraint. It doesn't care if you name it PRIMARY
KEY or REPLICATION KEY or whatever.
So, it's just a
Hi,
Tom Lane wrote:
It's the default foreign key reference
column(s) for the table
That's why I think it makes for a pretty good replication key as well.
Regards
Markus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 7/18/08, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
On 7/18/08, Tom Lane [EMAIL PROTECTED] wrote:
1. It's ludicrous to argue that standards compliance requires the
behavior-as-submitted. plpgsql is not specified by the SQL standard.
Yes, but it would
Hi,
I realize that you are talk about Slony, let me answer for the
Postgres-R case, anyway.
Gregory Stark wrote:
Hm, it occurs to me that really Slony should be saying
WHERE (col1,col2,...) = ('x','y','z',...)
Hm.. that would mean increasing the amount of work for the remote
backend,
Jonah H. Harris [EMAIL PROTECTED] writes:
Agreed. My thinking is that there's either something inherently wrong
with the implementation, or we're performing so many disk I/Os that
it's nearly equivalent to b-tree. Tom has a couple suggestions which
Xiao and I will explore.
I finally got a
Markus Wanner wrote:
Gregory Stark wrote:
It would be nice if there was a way for Slony to express to the server that
really, it only needs any UNIQUE NOT NULL combination of columns to match.
Once the server has any such combination which matches it can skip checking
the rest. I can't
On Jul 18, 2008, at 01:39, Michael Paesold wrote:
Calling regex functions with the case-insensitivity option would be
great. It should also be possible to rewrite replace() into
regexp_replace() by first escaping the regex meta characters.
Actually re-implementing those functions in a case
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Andrew Dunstan wrote:
OK, I have spent some time generating and filtering typdefs via objdump
on various platforms. I filtered them and Bruce's list to eliminate
items not actually found in the sources thus:
Did this go
Hi,
Alvaro Herrera wrote:
I think the point here is that you need to distinguish which tuple you
need to update. For this, our Replicator uses the primary key only;
there's no way to use another candidate key (unique not null). It would
certainly be possible to use a different candidate key,
Bruce Momjian wrote:
$ psql test
-- Output format is wrapped.
psql (8.4devel)
Type help for help.
Is this desirable? \set QUIET at the top of .psqlrc fixes it, but I am
wondering if we should be automatically doing quiet while .psqlrc is
processed.
I was
I just ran my original 16M word test case against the patched
version, and like Tom noted below, the tuples per bucket
calculation is wrong which results in identical index sizes
for both the original version and the hash-value-only version.
I suppose that the main point of #1 is to reduce index
On Fri, July 18, 2008 03:41, Tatsuo Ishii wrote:
Here is the lastest WITH RECURSIVE patches against CVS HEAD created by
Yoshiyuki Asaba and minor corrections by Tatsuo Ishii.
I tried this patch vs. CVS HEAD used my usual configure option with
only --with-prefix set, then tried to make, and
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
The attached patch is the proposal. It adds two global symbols:
* ExecutorRun_hook - replacing behavior of ExecutorRun()
* standard_ExecutorRun() - default behavior of ExecutorRun()
Applied.
And also modifies one funtion:
* ExecuteQuery() -
FYI,
I just patched the fill-factor calculation and re-ran my test.
The index size dropped from 513M to 43M which is the same disk
footprint as the corresponding btree index.
Have a nice weekend.
Ken
On Fri, Jul 18, 2008 at 12:23:14PM -0500, Kenneth Marshall wrote:
I just ran my original 16M
Abbas [EMAIL PROTECTED] writes:
I have come across a problem. When you try to access a temp table
created via SPI_EXEC, you get a table not found error.
SPI_EXEC(CREATE TEMP TABLE my_temp_table(first_name text, last_name
text), UTILITY);
SPI_EXEC(REVOKE ALL ON TABLE my_temp_table FROM
On Fri, Jul 18, 2008 at 7:15 PM, David Fetter [EMAIL PROTECTED] wrote:
On Fri, Jul 18, 2008 at 10:15:42AM +0530, Gurjeet Singh wrote:
On Fri, Jul 18, 2008 at 10:05 AM, Gurjeet Singh [EMAIL PROTECTED]
wrote:
On Fri, Jul 18, 2008 at 9:58 AM, Tom Lane [EMAIL PROTECTED] wrote:
I can't help suspecting that the two statements in question were run
in different sessions (or at least different transactions?).
...Robert
On Fri, Jul 18, 2008 at 9:11 PM, Tom Lane [EMAIL PROTECTED] wrote:
Abbas [EMAIL PROTECTED] writes:
I have come across a problem. When you try to access a
Awhile back we determined that the big stumbling block for building
Postgres universal binaries for OS X was that we were using ld
to produce intermediate SUBSYS.o files, and it didn't want to preserve
multi-architecture components of input .o files. Peter got rid of that
hack recently, so I
I looked at query operators for tsquery and here are some of the new
query operators for position based queries. I am just proposing some
changes and the questions I have.
1. What is the meaning of such a query operator?
foo #5 bar - true if the document has word foo followed by bar at
5th
40 matches
Mail list logo
