On Wed, 2009-11-25 at 07:36 +0100, Pavel Stehule wrote:
> > Moving records from a function to a table can be done with:
> > INSERT INTO mytable SELECT * FROM myfunc();
> > And that already works fine.
>
> It works, but COPY FROM myfunc() should be significantly faster. You
> can skip tuple store.
On Wed, 2009-11-25 at 07:31 +0100, Pavel Stehule wrote:
> > My disagreement with the row-by-row approach is more semantics than
> > performance. COPY translates records to bytes and vice-versa, and your
> > original patch maintains those semantics.
>
> uff, really
>
> COPY CSV ?
CSV is like text
2009/11/25 Pavel Stehule :
> 2009/11/25 Daniel Farina :
>> On Tue, Nov 24, 2009 at 10:23 PM, Jeff Davis wrote:
>>> On Wed, 2009-11-25 at 06:35 +0100, Pavel Stehule wrote:
I believe so using an "internal" minimalize necessary changes in COPY
implementation. Using a funcapi needs more work
LockDatabaseObject() doesn't perform AcceptInvalidationMessages(), yet
there is no comment as to why this has been left out. I thought we
cached more than just relation info in various places.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Thu, 2009-11-19 at 10:13 +0200, Heikki Linnakangas wrote:
> At backend start, we normally take
> RowExclusiveLock on the database in postinit.c, but you had to modify
> to acquire AccessShareLock instead in standby mode.
The consensus from earlier discussion was that allowing users to grab
Row
Hi,
On Fri, Nov 20, 2009 at 5:54 AM, Heikki Linnakangas
wrote:
> Thanks, I started to look at this again now.
Thanks a lot!
> I found the global LogstreamResult variable very confusing. It meant
> different things in different processes. So I replaced it with static
> globals in walsender.c and
2009/11/25 Daniel Farina :
> On Tue, Nov 24, 2009 at 10:23 PM, Jeff Davis wrote:
>> On Wed, 2009-11-25 at 06:35 +0100, Pavel Stehule wrote:
>>> I believe so using an "internal" minimalize necessary changes in COPY
>>> implementation. Using a funcapi needs more work inside COPY - you
>>> have to t
2009/11/25 Jeff Davis :
> On Wed, 2009-11-25 at 06:35 +0100, Pavel Stehule wrote:
>> I believe so using an "internal" minimalize necessary changes in COPY
>> implementation. Using a funcapi needs more work inside COPY - you
>> have to take some functionality from COPY to stream functions.
>> Proba
On Tue, Nov 24, 2009 at 10:23 PM, Jeff Davis wrote:
> On Wed, 2009-11-25 at 06:35 +0100, Pavel Stehule wrote:
>> I believe so using an "internal" minimalize necessary changes in COPY
>> implementation. Using a funcapi needs more work inside COPY - you
>> have to take some functionality from COPY
2009/11/25 Jeff Davis :
> On Tue, 2009-11-24 at 21:42 -0800, Daniel Farina wrote:
>> You are probably right. We could try coercing to bytea and back out
>> to bytes, although it seems like a superfluous cost to force
>> *everyone* to pay just to get the same bytes to a network buffer.
>
> Well, I
On Wed, 2009-11-25 at 06:35 +0100, Pavel Stehule wrote:
> I believe so using an "internal" minimalize necessary changes in COPY
> implementation. Using a funcapi needs more work inside COPY - you
> have to take some functionality from COPY to stream functions.
> Probably the most slow operations i
On Tue, 2009-11-24 at 21:42 -0800, Daniel Farina wrote:
> You are probably right. We could try coercing to bytea and back out
> to bytes, although it seems like a superfluous cost to force
> *everyone* to pay just to get the same bytes to a network buffer.
Well, I suppose only performance will te
2009/11/25 Daniel Farina :
> On Tue, Nov 24, 2009 at 9:35 PM, Pavel Stehule
> wrote:
>> 2009/11/25 Daniel Farina :
>>> On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule
>>> wrote:
It depends on design. I don't thing so internal is necessary. It is
just wrong design.
>>>
>>> Depends on ho
Emmanuel Cecchet wrote:
> Should we add the 'WITH (...) TABLESPACE tbs' options to the syntax
> since they are supported?
Added the description.
> Do we support ALTER ... SET TABLESPACE?
DROP/ALTER PARTITION are synonyms for DROP/ALTER TABLE.
SET TABLESPACE is also supported. Added the descr
On Wed, Nov 25, 2009 at 3:26 AM, Tom Lane wrote:
> Greg Stark writes:
>> Well the only thing that's been discussed is having vacuum require a
>> minimum age before considering a transaction visible to all to reduce
>> the chance of conflicts on cleanup records.
>
> [ shrug... ] Call me Cassandra
On Tue, Nov 24, 2009 at 9:35 PM, Pavel Stehule wrote:
> 2009/11/25 Daniel Farina :
>> On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule
>> wrote:
>>> It depends on design. I don't thing so internal is necessary. It is
>>> just wrong design.
>>
>> Depends on how lean you want to be when doing large
Greg Smith wrote:
I just made a few updates to
http://wiki.postgresql.org/wiki/Table_partitioning , merging in the
stuff that had been on the ToDo page and expanding the links to
discussion on this list a bit. The number of submitted patches over
the last couple of years that handle some subs
2009/11/25 Daniel Farina :
> On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule
> wrote:
>> It depends on design. I don't thing so internal is necessary. It is
>> just wrong design.
>
> Depends on how lean you want to be when doing large COPY...right now
> the cost is restricted to having to call a f
On Tue, Nov 24, 2009 at 9:13 PM, Jeff Davis wrote:
>
> I still don't see any reason to force it to be record by record though.
> If the point is to push data from a table into a remote table, why
> should the copied data be translated out of binary format into a record,
> and then back into binar
* It uses dedicated 'SExxx' error codes, but I think they should belong to
the same family of ERRCODE_INSUFFICIENT_PRIVILEGE (42501).
>>> I already uses predefined error code, if exist.
>> What I meant was: there are no problem to add new error codes for SE-PgSQL,
>> but I think the val
On Wed, 2009-11-25 at 03:12 +, Greg Stark wrote:
> On Wed, Nov 25, 2009 at 2:10 AM, Tom Lane wrote:
> > As long as there's not anything the master actually does differently
> > then I can't see where there'd be any performance testing to do. What's
> > bothering me about this is that it seems
On Tue, 2009-11-24 at 23:44 -0500, Tom Lane wrote:
> If you do that, then there is no possibility of ever using this feature
> except with C-coded functions, which seems to me to remove most of
> whatever use-case there was.
It fits the use case involving dblink (or dblink-like modules).
Maybe th
On Tue, Nov 24, 2009 at 8:45 PM, Pavel Stehule wrote:
> It depends on design. I don't thing so internal is necessary. It is
> just wrong design.
Depends on how lean you want to be when doing large COPY...right now
the cost is restricted to having to call a function pointer and a few
branches. If
I just made a few updates to
http://wiki.postgresql.org/wiki/Table_partitioning , merging in the
stuff that had been on the ToDo page and expanding the links to
discussion on this list a bit. The number of submitted patches over the
last couple of years that handle some subset of the desired f
2009/11/25 Jeff Davis :
> On Tue, 2009-11-24 at 14:39 +0100, Pavel Stehule wrote:
>> a) good designed C API like:
>>
>> initialise_functions(fcinfo) -- std fcinfo
>> consument_process_tuple(fcinfo) -- gets standard row -- Datum
>> dvalues[] + Row description
>> producent_process_tuple(fci
Jeff Davis writes:
> Don't you still need the functions to accept an argument of type
> internal? Otherwise, we lose the ability to copy a buffer to the dblink
> connection, which was the original motivation.
If you do that, then there is no possibility of ever using this feature
except with C-co
On Tue, 2009-11-24 at 14:39 +0100, Pavel Stehule wrote:
> a) good designed C API like:
>
>initialise_functions(fcinfo) -- std fcinfo
>consument_process_tuple(fcinfo) -- gets standard row -- Datum
> dvalues[] + Row description
>producent_process_tuple(fcinfo) -- returns standard row -
Itagaki Takahiro wrote:
> KaiGai Kohei wrote:
>
>>> CREATE TABLE tbl (...) SECURITY CONTEXT '...'
>>> * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
>> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
>> to avoid syntax conflicts to "DEFAULT b_expr" opt
Emmanuel Cecchet wrote:
> I think that other databases allows the
> user to define a tablespace for each partition in the create table
> statement.
WITH and TABLESPACE clause are supported for each partition.
=# CREATE TABLE parent (...) PARTITION BY (key)
(
PARTITION child_1 VALU
Hi,
Sorry for commenting only now but I think that we need to be able to
store the partitions in different tablespaces. Even if originally the
create table creates all partitions in the same tablespace, individual
partitions should be allowed to be moved in different tablespaces using
alter t
Itagaki Takahiro wrote:
Emmanuel Cecchet wrote:
I guess the problem of handling user triggers is still open.
If we allow triggers on partitions, badly written logic could lead to
infinite loops in routing.
Infinite loops are not a partition-related problem, no?
We can also find infin
Greg Stark writes:
> Well the only thing that's been discussed is having vacuum require a
> minimum age before considering a transaction visible to all to reduce
> the chance of conflicts on cleanup records.
[ shrug... ] Call me Cassandra. I am not concerned about what has or
has not been discu
On Wed, Nov 25, 2009 at 2:10 AM, Tom Lane wrote:
> As long as there's not anything the master actually does differently
> then I can't see where there'd be any performance testing to do. What's
> bothering me about this is that it seems likely that we'll find places
> where the master has to do t
KaiGai Kohei wrote:
> > CREATE TABLE tbl (...) SECURITY CONTEXT '...'
> > * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
>
> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
> to avoid syntax conflicts to "DEFAULT b_expr" option.
There might be anoth
On Tue, 2009-11-24 at 00:54 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 12:29 AM, Hannu Krosing wrote:
> > COPY stdin TO udf();
>
> If stdin becomes (is?) a legitimate source of records, then this patch
> will Just Work.
>
STDIN is a source of bytes representing a set of records. Curr
Emmanuel Cecchet wrote:
> I guess the problem of handling user triggers is still open.
> If we allow triggers on partitions, badly written logic could lead to
> infinite loops in routing.
Infinite loops are not a partition-related problem, no?
We can also find infinite loops in user defined fu
On Mon, 2009-11-23 at 20:44 +0300, Teodor Sigaev wrote:
> Old way:
> SELECT coordinates, (coordinates <-> '5.0,5.0'::point) AS dist FROM
> spots
> order by dist asc LIMIT 10;
>
> Time: 1024.242 ms
>
> knn-search:
> SELECT coordinates, (coordinates <-> '5.0,5.0'::point) AS dist FROM
> spots
> WHER
Simon Riggs writes:
> Tom Lane wrote:
>> There's no equivalent of XLogArchivingActive()?
> We've tried hard to have it "just work". But I wonder whether we should
> have a parameter to allow performance testing on the master? If nobody
> finds any issues then we can remove it again, or at least m
KaiGai Kohei wrote:
> Ross J. Reedstrom wrote:
>> On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
>>> Itagaki Takahiro wrote:
* CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
Is the syntax " SECURITY_CONTEXT" natural in English?
>>> We need to put a reserved to
On Sat, 2009-11-21 at 23:00 +0200, Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Heikki Linnakangas writes:
> >> Tom Lane wrote:
> >>> There's no equivalent of XLogArchivingActive()?
> >
> >> XLogArchivingMode() == false enables us to skip WAL-logging in
> >> operations like CLUSTER or COPY, wh
On Sat, 2009-11-21 at 20:20 +0200, Heikki Linnakangas wrote:
> That causes some headaches for Hot Standby
I say leave HS as it is and we can clean up when we do the VFectomy.
It isn't really a headache, the code works easily enough. I agree its
ugly and it should eventually be removed.
Let's no
2009/11/25 Tom Lane :
> Hitoshi Harada writes:
>> Rewriting my frame support types patch to allow any expression in
>> PRECEDING/FOLLOWING clause, I found the syntax below in PG conflicts:
>
> Yeah, we ran into that in the original WINDOW patch IIRC, and found some
> solution to it that got taken
On Tue, Nov 24, 2009 at 05:43:00PM -0500, Tom Lane wrote:
> Roger Leigh writes:
> > On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
> >> I wonder whether the most prudent solution wouldn't be to prevent
> >> default use of linestyle=unicode if ~/.psqlrc hasn't been read.
>
> > This prob
Roger Leigh writes:
> On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
>> I wonder whether the most prudent solution wouldn't be to prevent
>> default use of linestyle=unicode if ~/.psqlrc hasn't been read.
> This problem is caused when there's a mismatch between the
> client encoding an
Ross J. Reedstrom wrote:
On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
Itagaki Takahiro wrote:
* CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
Is the syntax " SECURITY_CONTEXT" natural in English?
We need to put a reserved token, such as "AS", prior to the SECURI
On Tue, Nov 24, 2009 at 02:19:27PM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > Anyway, that patch to set the client encoding automatically from the
> > locale sounds even more useful now.
>
> I think you're being overoptimistic to assume that that's going to
> eliminate the issue. It m
On Tue, Nov 24, 2009 at 4:49 PM, Oleg Bartunov wrote:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>
>> Oleg Bartunov writes:
>>>
>>> what's benefit of using linestyle=unicode ? I like old ASCII style
>>> for console.
>>
>> Well, I have to grant that it looks pretty spiffy on a unicode-enabled
>> displ
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
what's benefit of using linestyle=unicode ? I like old ASCII style
for console.
Well, I have to grant that it looks pretty spiffy on a unicode-enabled
display. Whether that's enough reason to risk breaking things for
people with non
Oleg Bartunov writes:
> what's benefit of using linestyle=unicode ? I like old ASCII style
> for console.
Well, I have to grant that it looks pretty spiffy on a unicode-enabled
display. Whether that's enough reason to risk breaking things for
people with non-unicode-enabled displays is certainly
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
why 8.4 has no real problem ?
Because we never tried to use utf8 table decoration before. This
is collateral damage from Roger Leigh's recent patches.
The problem is evidently that Oleg is depending on ~/.psqlrc to
set client_enco
On Tue, Nov 24, 2009 at 11:57:06AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > The next step I plan is to move the large multi-line string literal
> > macros (PERLBOOT, SAFE_OK etc) into external perl code files.
> > That'll make refactoring, extending and maintaining that perl
> > code far sim
On Tue, Nov 24, 2009 at 2:07 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> If it did so, that would be outside the apparent meaning of the
>> command, which is to do nothing if an object of that name exists.
>> That's why we've gone with CREATE OR REPLACE instead.
>
> I think that "fail on exi
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Yes, I'd expect the user to custom-code it, because it's not clear
>> exactly which properties the script would be depending on and which
>> ones it's okay to allow to vary. To take just one example, is it
>> okay if the object ownership is different
Scott Marlowe writes:
> On Tue, Nov 24, 2009 at 11:34 AM, Tom Lane wrote:
>> The point would be to reduce the risk that you're changing the language
>> definition in a surprising way. Extra args would imply that you're
>> trying to install a non-default definition of the language.
> But if you'
Peter Eisentraut writes:
> Anyway, that patch to set the client encoding automatically from the
> locale sounds even more useful now.
I think you're being overoptimistic to assume that that's going to
eliminate the issue. It might patch things for Oleg's particular
configuration; but the real pr
On tis, 2009-11-24 at 21:55 +0300, Oleg Bartunov wrote:
> > Seems like a mismatch between client encoding and actual locale
> > environment.
>
> why 8.4 has no real problem ?
Because table formatting with Unicode characters is a new feature.
Anyway, that patch to set the client encoding automat
Oleg Bartunov writes:
> why 8.4 has no real problem ?
Because we never tried to use utf8 table decoration before. This
is collateral damage from Roger Leigh's recent patches.
The problem is evidently that Oleg is depending on ~/.psqlrc to
set client_encoding the way he wants it, but that file
Tom Lane wrote:
> If it did so, that would be outside the apparent meaning of the
> command, which is to do nothing if an object of that name exists.
> That's why we've gone with CREATE OR REPLACE instead.
I think that "fail on existence of an object conflicting with given
definition" is behav
On Tue, 24 Nov 2009, Peter Eisentraut wrote:
On tis, 2009-11-24 at 21:32 +0300, Oleg Bartunov wrote:
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
On Tue, 24 Nov 2009, Tom Lane wrote:
Hm, you only see it for -l and not for all tabular output? That's
a bit strange.
yes, I'm
On Tue, Nov 24, 2009 at 11:34 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane wrote:
>>> But actually I thought we had more or less concluded that CREATE OR
>>> REPLACE LANGUAGE would be acceptable (perhaps only if it's given
>>> without any extra args?).
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
On Tue, 24 Nov 2009, Tom Lane wrote:
What's your locale environment? ("env | grep ^L" would help.)
LC_COLLATE=ru_RU.KOI8-R
LANG=C
LC_CTYPE=ru_RU.KOI8-R
Hmm, I can duplicate the fact that psql -l uses utf8 characters
(because it
On tis, 2009-11-24 at 21:32 +0300, Oleg Bartunov wrote:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>
> > Oleg Bartunov writes:
> >> On Tue, 24 Nov 2009, Tom Lane wrote:
> >>> Hm, you only see it for -l and not for all tabular output? That's
> >>> a bit strange.
> >
> >> yes, I'm surprising myself. T
Oleg Bartunov writes:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>> What's your locale environment? ("env | grep ^L" would help.)
> LC_COLLATE=ru_RU.KOI8-R
> LANG=C
> LC_CTYPE=ru_RU.KOI8-R
Hmm, I can duplicate the fact that psql -l uses utf8 characters
(because it connects to the postgres DB which
Robert Haas writes:
> On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane wrote:
>> But actually I thought we had more or less concluded that CREATE OR
>> REPLACE LANGUAGE would be acceptable (perhaps only if it's given
>> without any extra args?).
> I'm not sure there's any value in that restriction - s
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
On Tue, 24 Nov 2009, Tom Lane wrote:
Hm, you only see it for -l and not for all tabular output? That's
a bit strange.
yes, I'm surprising myself. Teodor has no problem, but he is under FreeBSD,
while I use slackware linux. Here is
Oleg Bartunov writes:
> On Tue, 24 Nov 2009, Tom Lane wrote:
>> Hm, you only see it for -l and not for all tabular output? That's
>> a bit strange.
> yes, I'm surprising myself. Teodor has no problem, but he is under FreeBSD,
> while I use slackware linux. Here is ldd output.
What's your local
"Kevin Grittner" writes:
> Tom Lane wrote:
>> The argument against CINE is that it's unsafe.
> By no means rhetorically, is that based on the assumption that the
> statement would not validate that the existing object (if any) matches
> the supplied definition?
If it did so, that would be outs
On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> So we're conceding that this is a valid need and people will now have
>> a way to meet it. Is the argument against having CINE syntax that it
>> would be more prone to error than the above, or that the code would be
On Tue, 24 Nov 2009, Tom Lane wrote:
Oleg Bartunov writes:
I have problem with CVS HEAD (noticed a week or so ago) -
psql -l show garbage instead of -|+. Looks, like utf-8 symbols used
instead that ascii characters.
Hm, you only see it for -l and not for all tabular output? That's
a bit str
Oleg Bartunov writes:
> I have problem with CVS HEAD (noticed a week or so ago) -
> psql -l show garbage instead of -|+. Looks, like utf-8 symbols used
> instead that ascii characters.
Hm, you only see it for -l and not for all tabular output? That's
a bit strange.
rega
Hitoshi Harada writes:
> Rewriting my frame support types patch to allow any expression in
> PRECEDING/FOLLOWING clause, I found the syntax below in PG conflicts:
Yeah, we ran into that in the original WINDOW patch IIRC, and found some
solution to it that got taken out again when the functionalit
Tom Lane wrote:
> The argument against CINE is that it's unsafe.
By no means rhetorically, is that based on the assumption that the
statement would not validate that the existing object (if any) matches
the supplied definition?
> The fragment proposed by Andrew is no safer, of course, but it
"Kevin Grittner" writes:
> So we're conceding that this is a valid need and people will now have
> a way to meet it. Is the argument against having CINE syntax that it
> would be more prone to error than the above, or that the code would be
> so large and complex as to create a maintenance burden
Hi there,
I have problem with CVS HEAD (noticed a week or so ago) -
psql -l show garbage instead of -|+. Looks, like utf-8 symbols used
instead that ascii characters.
List of databases
NameБ■┌ Owner Б■┌ Encoding Б■┌ Collation Б■┌Ct
Andrew Dunstan wrote:
> Part of the motivation for allowing inline blocks was to allow for
> conditional logic. So you can do things like:
>
> DO $$
>
> begin
> if not exists (select 1 from pg_tables
> where schemaname = 'foo'
> and tablenam
Rewriting my frame support types patch to allow any expression in
PRECEDING/FOLLOWING clause, I found the syntax below in PG conflicts:
frame_extent: frame_bound { ... }
| BETWEEN frame_bound AND frame_bound { ... }
;
frame_bound: UNBOUNDED PRECEDING { ... }
| UNBOUNDED FOLLOWING { ... }
Tim Bunce writes:
> The next step I plan is to move the large multi-line string literal
> macros (PERLBOOT, SAFE_OK etc) into external perl code files.
> That'll make refactoring, extending and maintaining that perl
> code far simpler.
That does not seem like it accomplishes anything from the use
I've started work on the enhancements to plperl I outlined on pg-general
(XXX thread)
I have a working implementation of those changes, plus some performance
enhancements, that I'm now re-working into a clean set of tested and
polished patches.
This patch is a first step that doesn't add any extra
On Tue, Nov 24, 2009 at 03:12:43PM +0900, KaiGai Kohei wrote:
> Itagaki Takahiro wrote:
> > * CREATE TABLE tbl (col integer AS SECURITY_CONTEXT = '...')
> > Is the syntax " SECURITY_CONTEXT" natural in English?
>
> We need to put a reserved token, such as "AS", prior to the SECURITY_CONTEXT
> to
On Sat, Nov 21, 2009 at 12:49:33PM -0800, Mark Richardson wrote:
> I'm pretty sure the problem I found is related to this, but I found that ecpg
> doesn't process booleans correctly- this was in a old version of postgres (I
> think it was 7.4.2). I traced it down in the code, and there is a sectio
Itagaki Takahiro wrote:
I just edited a wiki page for this discussion.
I hope it can be a help.
http://wiki.postgresql.org/wiki/Table_partitioning
I guess the problem of handling user triggers is still open.
If we allow triggers on partitions, badly written logic could lead to
infinite loops
On Mon, Nov 23, 2009 at 9:37 PM, Andrew Dunstan wrote:
>
>
> Greg Smith wrote:
>>
>> I haven't heard anything from Andrew about ragged CVS import either. I
>> think that ultimately those features are useful, but just exceed what the
>> existing code could be hacked to handle cleanly.
>
> The patc
2009/11/24 Hannu Krosing :
> On Tue, 2009-11-24 at 05:00 -0800, Daniel Farina wrote:
>> On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule
>> wrote:
>
>> > then syntax should be:
>> >
>> > COPY table TO streamname(parameters)
>> >
>> > COPY table TO filestream('/tmp/foo.dta') ...
>> > COPY table TO d
On Mon, Nov 23, 2009 at 8:46 PM, Greg Smith wrote:
> You know how people complain about how new contributors are treated here?
> Throwing out comments like this, that come off as belittling to other
> people's work, doesn't help. All I was suggesting was that Dan wasn't
> developing this in comp
Magnus Hagander writes:
> ISTM that it should be as simple as the attached patch. Seems to work
> for me :-) But I'm no autoconf guru, so maybe I missed something?
This patch sort of begs the question "what about enable-thread-safety-force?"
That looks even more like a wart now than it did before
On Tue, 2009-11-24 at 05:00 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule
> wrote:
> > then syntax should be:
> >
> > COPY table TO streamname(parameters)
> >
> > COPY table TO filestream('/tmp/foo.dta') ...
> > COPY table TO dblinkstream(connectionstring) ...
You
2009/11/24 Daniel Farina :
> On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule
> wrote:
>> 2009/11/24 Daniel Farina :
>>> On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule
>>> wrote:
Hello
I thing, so this patch is maybe good idea. I am missing better
function specification. Speci
On Tue, 2009-11-24 at 03:48 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 3:25 AM, Hannu Krosing wrote:
> > On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
> >> On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
> >> > On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing
> >> > wro
On Tue, Nov 24, 2009 at 4:37 AM, Pavel Stehule wrote:
> 2009/11/24 Daniel Farina :
>> On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> I thing, so this patch is maybe good idea. I am missing better
>>> function specification. Specification by name isn't enough - we can
2009/11/24 Daniel Farina :
> On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule
> wrote:
>> Hello
>>
>> I thing, so this patch is maybe good idea. I am missing better
>> function specification. Specification by name isn't enough - we can
>> have a overloaded functions. This syntax doesn't allow to us
Teodor Sigaev wrote:
>>> 1. KNNGiST is about 5% slower than GiST on non-knn search queries, like
>>> contains or contained by, because of some overhead of new algorithm of
>>> tree traversal
>>
>> Is it possible to use the regular GiST traversal algorithm on a
>> KNNGiST-tree, when performing r
On Sat, Nov 21, 2009 at 08:29, Magnus Hagander wrote:
> 2009/11/20 Peter Eisentraut :
>> On fre, 2009-11-20 at 08:39 +0100, Magnus Hagander wrote:
>>> 2009/11/20 Peter Eisentraut :
>>> > On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote:
>>> >> Is there any actual reason why we are building
I think you'll need to work on that. A WHERE qual shouldn't imply a sort
order. You'll have to teach the planner how to use the index to speed up
a query in the first form.
Of course, right now it is a working prototype.
1. KNNGiST is about 5% slower than GiST on non-knn search queries, like
On Tue, Nov 24, 2009 at 3:25 AM, Hannu Krosing wrote:
> On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
>> On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
>> > On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing
>> > wrote:
>> >> Can't you use existing aggregate function design ?
>> >>
On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
> > On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing
> > wrote:
> >> Can't you use existing aggregate function design ?
> >>
> >> CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
>
On Tue, 2009-11-24 at 09:46 +, Thom Brown wrote:
> 2009/11/24 Hannu Krosing
> On Sun, 2009-11-22 at 18:51 -0500, Tom Lane wrote:
> > Craig Ringer writes:
> > > I do think this comes up often enough that a built-in
> trigger "update
> > > named column wi
On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing wrote:
>> Can't you use existing aggregate function design ?
>>
>> CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
>> SFUNC = sfunc,
>> STYPE = state_data_type
>> [ , FINALFUNC =
On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing wrote:
> Can't you use existing aggregate function design ?
>
> CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
> SFUNC = sfunc,
> STYPE = state_data_type
> [ , FINALFUNC = ffunc ]
> [ , INITCOND = initial_condition ]
> [ , SORTOP
On Tue, 2009-11-24 at 02:37 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule
> wrote:
> > Hello
> >
> > I thing, so this patch is maybe good idea. I am missing better
> > function specification. Specification by name isn't enough - we can
> > have a overloaded function
On Tue, Nov 24, 2009 at 2:10 AM, Pavel Stehule wrote:
> Hello
>
> I thing, so this patch is maybe good idea. I am missing better
> function specification. Specification by name isn't enough - we can
> have a overloaded functions. This syntax doesn't allow to use explicit
> cast - from my personal
1 - 100 of 110 matches
Mail list logo
