Joe Conway wrote:
Tom Lane wrote:
Tommy Gildseth [EMAIL PROTECTED] writes:
One obvious disadvantage of this approach, is that I need to connect
and disconnect in every function. A possible solution to this, would
be having a function f.ex dblink_exists('connection_name') that
returns
On Mon, 2008-06-02 at 22:40 +0200, Andreas 'ads' Scherbaum wrote:
On Mon, 02 Jun 2008 11:52:05 -0400 Chris Browne wrote:
[EMAIL PROTECTED] (Andreas 'ads' Scherbaum) writes:
On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote:
Well, yes, but you do know about archive_timeout,
Martijn van Oosterhout napsal(a):
On Mon, Jun 02, 2008 at 11:08:55AM -0700, Jeff Davis wrote:
http://wiki.postgresql.org/wiki/Todo:Collate
The last reference I see on that page is from 2005. Is there any updated
information? Are there any major obstacles holding this up aside from
the platform
Mike schrieb:
Hello,
I’m new to the core PostgreSQL code, so pardon the question if the
answer is really obvious, and I’m just missing it, but I’ve got a
relatively large web application that uses PostgreSQL as a back-end
database, and we’re heavily using memcached to cache frequently
to add some complexity to this topic :-) Please note I admit upfront
I am not familiar with every parameter out there, but during my quest
in finding bottleneck while stressing the back-end I find many GUC
parameters with names that show they should be interesting.
I read the comments, the
Folks,
I've noticed that queries of the form
SELECT DISTNCT foo, bar, baz
FROM quux
WHERE ...
perform significantly worse than the equivalent using GROUP BY.
SELECT foo, bar, baz
FROM quux
WHERE ...
GROUP BY foo, bar, baz
Where would I start looking in order to make them actually equivalent
Hello David
http://www.postgresql.org/docs/faqs.TODO.html
Consider using hash buckets to do DISTINCT, rather than sorting
This would be beneficial when there are few distinct values. This is
already used by GROUP BY.
Regards
Pavel Stehule
2008/6/3 David Fetter [EMAIL PROTECTED]:
Folks,
I've
On Tue, Jun 03, 2008 at 03:36:44PM +0200, Pavel Stehule wrote:
Hello David
http://www.postgresql.org/docs/faqs.TODO.html
Consider using hash buckets to do DISTINCT, rather than sorting This
would be beneficial when there are few distinct values. This is
already used by GROUP BY.
It's
2008/6/3 David Fetter [EMAIL PROTECTED]:
On Tue, Jun 03, 2008 at 03:36:44PM +0200, Pavel Stehule wrote:
Hello David
http://www.postgresql.org/docs/faqs.TODO.html
Consider using hash buckets to do DISTINCT, rather than sorting This
would be beneficial when there are few distinct values. This
On Tue, Jun 03, 2008 at 01:17:43AM -0400, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I would like to add the flags given to pg_dump into the output of the
pg_dump
file.
+1, FWIW
Anyone see any issues with this?
I'm a bit worried about breaking diff-equality of matching
On Jun 3, 2008, at 02:27, Zdenek Kotala wrote:
The proposal of GSoc is there:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00857.php
It should create basic framework for full SQL COLLATION support. All
comments are welcome.
That looks great, Zdenek. I'm very excited to have
This is far more complicated than I thought.
Of course, phrase search should be able to use indexes.
I can probably look into how to use index. Any pointers on this?
src/backend/utils/adt/tsginidx.c, if you invent operation # in tsquery then you
will have index support with minimal effort.
David E. Wheeler napsal(a):
On Jun 3, 2008, at 02:27, Zdenek Kotala wrote:
The proposal of GSoc is there:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00857.php
It should create basic framework for full SQL COLLATION support. All
comments are welcome.
That looks great, Zdenek.
Why we need norms?
We don't need norms at all - all matched HeadlineWordEntry already marked by
HeadlineWordEntry-item! If it equals to NULL then this word isn't contained in
tsquery.
hlCover does the exact thing that Cover in tsrank does which is to find
the cover that contains the
On Jun 3, 2008, at 12:06, Zdenek Kotala wrote:
It is simple. SQL standard does not specify notation for that
(chapter 11.34). But there is proposed notation:
CREATE COLLATION collation name FOR character set specification
FROM existing collation name [ pad characteristic ] [ case
David E. Wheeler napsal(a):
On Jun 3, 2008, at 12:06, Zdenek Kotala wrote:
It is simple. SQL standard does not specify notation for that (chapter
11.34). But there is proposed notation:
CREATE COLLATION collation name FOR character set specification
FROM existing collation name [ pad
2008/6/3 Zdenek Kotala [EMAIL PROTECTED]:
David E. Wheeler napsal(a):
On Jun 3, 2008, at 02:27, Zdenek Kotala wrote:
The proposal of GSoc is there:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00857.php
It should create basic framework for full SQL COLLATION support. All
Pavel Stehule napsal(a):
2008/6/3 Zdenek Kotala [EMAIL PROTECTED]:
David E. Wheeler napsal(a):
On Jun 3, 2008, at 02:27, Zdenek Kotala wrote:
The proposal of GSoc is there:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00857.php
It should create basic framework for full SQL
On May 28, 2008, at 1:22 PM, Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Tomasz Rybak [EMAIL PROTECTED] writes:
I tried to use COPY to import 27M rows to table:
CREATE TABLE sputnik.ccc24 (
station CHARACTER(4) NOT NULL REFERENCES
sputnik.station24 (id),
moment
On Tue, 2008-06-03 at 21:26 +0200, Zdenek Kotala wrote:
The first step is per database, because it is relative easy. Collation
per-column is very difficult. It requires a lot of changes (parser, planer,
executor...) in whole source code, because you need to keep collation
information
On May 27, 2008, at 2:35 PM, Simon Riggs wrote:
After some discussions at PGCon, I'd like to make some proposals for
hint bit setting with the aim to reduce write overhead.
For those that missed it... http://wiki.postgresql.org/wiki/Hint_Bits
(see archive reference at bottom).
--
Decibel!,
On May 30, 2008, at 9:51 AM, Simon Riggs wrote:
On Thu, 2008-05-29 at 19:18 -0500, Decibel! wrote:
Is there a reason that we can't add a trigger to a table while a
select is running? This is a serious pain when trying to setup
londiste or slony.
This is constrained by locking.
There are a
On Tue, 2008-06-03 at 16:48 -0500, Decibel! wrote:
On May 30, 2008, at 9:51 AM, Simon Riggs wrote:
On Thu, 2008-05-29 at 19:18 -0500, Decibel! wrote:
Is there a reason that we can't add a trigger to a table while a
select is running? This is a serious pain when trying to setup
londiste
On May 29, 2008, at 6:08 PM, Jan Urbański wrote:
Now about the idea itself:
http://www.informatik.uni-augsburg.de/de/lehrstuehle/dbis/db/
publications/all_db_tech-reports/tr-2001-7_kie_koe/
tr-2001-7_kie_koe.pdf
That's one of the basic papers about Preference SQL, explaining
what it's all
Decibel! wrote:
On May 29, 2008, at 6:08 PM, Jan Urbański wrote:
Preference SQL is an extension to regular SQL, that allows expressing
preferences in SQL queries. Preferences are like soft WHERE clauses.
This seems like a subset of http://pgfoundry.org/projects/qbe/ ... or do
I
Jan,
I'm still working on producing a comparision of preference SQL and the
skyline operator, more to follow soon.
The big problem with all of these is that there's no standards on
approximate queries yet. So we're reluctant to support syntax extensions
for them.
--
--Josh
Josh Berkus
Josh Berkus wrote:
Jan,
I'm still working on producing a comparision of preference SQL and the
skyline operator, more to follow soon.
The big problem with all of these is that there's no standards on
approximate queries yet. So we're reluctant to support syntax extensions
for them.
Yes,
Jan Urbański wrote:
Maybe I should talk to my thesis supervisor and find out if
implementing window functions would be an equally good subject...
I suppose having window functions would be a nice thing? To be honest
- I need a thesis subject and I like fiddling with Postgres.
Window
My main argument for using Cover instead of hlCover was that Cover will
be faster. I tested the default headline generation that uses hlCover
with the current patch that uses Cover. There was not much difference.
So I think you are right in that we do not need norms and we can just
use hlCover.
I
On Tuesday 03 June 2008 01:17:43 Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
Anyone see any issues with this?
I'm a bit worried about breaking diff-equality of matching dumps,
If you are calling pg_dump with different flags, it seems likely your breaking
diff equality anyway so
On Tue, 2008-06-03 at 22:16 +0400, Teodor Sigaev wrote:
This is far more complicated than I thought.
Of course, phrase search should be able to use indexes.
I can probably look into how to use index. Any pointers on this?
src/backend/utils/adt/tsginidx.c, if you invent operation # in
On Sun, Jun 01, 2008 at 01:43:22PM -0400, Tom Lane wrote:
power to him. (Is the replica-hooks-discuss list still working?) But
Yes. And silent as ever. :-)
A
--
Andrew Sullivan
[EMAIL PROTECTED]
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-hackers mailing list
On Tue, 3 Jun 2008, Paul van den Bogaard wrote:
So overhauling the GUC parameters is one step, but adding proper
instrumentation in order to really measure the impact of the new setting
is necessary too.
Correct, but completely off-topic regardless. One problem to be solved
here is to take
James William Pye [EMAIL PROTECTED] writes:
On Tue, Jun 03, 2008 at 01:17:43AM -0400, Tom Lane wrote:
but mainly I don't see the point.
It's informative, no?
Well, the stuff included into the dump by pg_dump -v is informative,
too. But we stopped doing that by default because of complaints.
Jeff Davis [EMAIL PROTECTED] writes:
Right now typmod is already passed to all those layers, right? Would it
be a useful intermediate step to use typmod to hold this information for
the text type?
No, it would not, because typmod doesn't propagate through functions.
Hannu Krosing wrote:
The simplest form of synchronous wal shipping would not even need
postgresql running on slave, just a small daemon which
reports when wal
blocks are a) received and b) synced to disk.
While that does sound simple, I'd presume that most people would want the
guarantee
On Tue, Jun 03, 2008 at 01:53:56PM -0700, Jeff Davis wrote:
On Tue, 2008-06-03 at 21:26 +0200, Zdenek Kotala wrote:
The first step is per database, because it is relative easy. Collation
per-column is very difficult. It requires a lot of changes (parser, planer,
executor...) in whole
Hello,
I need to use query like:
select (insert into test (a) values (x) returning b),c from anytable
where condition
but it say
ERROR: syntax error at or near into
Is this a bug?
Function does not work too:
create function addt(..) returning .. as 'insert ... returning ..'
language
38 matches
Mail list logo
