Mark Mielke <[EMAIL PROTECTED]> writes:
> I'm noticing a massive reduction in on disk storage required for my
> database that I believe is primarily attributable due to Tom's reduced
> overhead for short strings.
Twasn't my work; Greg Stark gets most of the credit for that one, and
you might be
On Sun, Feb 24, 2008 at 6:52 PM, Jochem van Dieten <[EMAIL PROTECTED]> wrote:
>
> Or we could have a switch that specifies a directory and have pg_dump
> split the dump not just in pre-schema, data and post-schema, but also
> split the data in a file for each table. That would greatly facilitate
Hi
dblink in 8.3 blocks without any possibility of interrupting it while
waiting for an answer from the remote server. Here is a strace
[pid 27607] rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
[pid 27607] sendto(56, "Q\0\0\0008lock table travelhit.booking_code in
exclusive mode\0", 57, 0,
Tom Lane wrote:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
Not stupid, it doesn't work :) This was a limitation of the original
design based on (IIRC) executor-related issues.
There are definitional issues not only implementation ones; in
particular, in subquery-like cases it's ent
On Sun, Feb 24, 2008 at 5:44 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> > Not stupid, it doesn't work :) This was a limitation of the original
> > design based on (IIRC) executor-related issues.
>
> There are definitional issues not only implementa
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> Not stupid, it doesn't work :) This was a limitation of the original
> design based on (IIRC) executor-related issues.
There are definitional issues not only implementation ones; in
particular, in subquery-like cases it's entirely unclear how many t
On Sun, Feb 24, 2008 at 4:21 PM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> I tried using insert ... delete ... return ... and get a syntax error:
Yeah...
> In the past I've executed insert ... select and then the delete.
> However, I believe there is race condition here as the delete may see
>
On Sun, Feb 24, 2008 at 10:39 PM, Guillaume Smet
<[EMAIL PROTECTED]> wrote:
> On Sun, Feb 24, 2008 at 10:21 PM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> > I'm at PostgreSQL 8.3 for my production database and everything is
> > working great. I had no problems converting free text search from 8.
Hi Mark,
On Sun, Feb 24, 2008 at 10:21 PM, Mark Mielke <[EMAIL PROTECTED]> wrote:
> I'm at PostgreSQL 8.3 for my production database and everything is
> working great. I had no problems converting free text search from 8.2 to
> 8.3, and I really like the improvements.
>
> I tried using insert
Hi all:
I'm at PostgreSQL 8.3 for my production database and everything is
working great. I had no problems converting free text search from 8.2 to
8.3, and I really like the improvements.
I tried using insert ... delete ... return ... and get a syntax error:
pccyber=# insert into product_ma
On Thu, 2008-02-21 at 13:26 +0900, ITAGAKI Takahiro wrote:
> This is a proposal of fast data loading using batch update of indexes for 8.4.
> It is a part of pg_bulkload (http://pgbulkload.projects.postgresql.org/) and
> I'd like to integrate it in order to cooperate with other parts of postgres.
>
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Plus, the fact that we don't support "default" specifications in
pl/pgsql for row types turns this inconvenience into a major PITA,
You mean initialization expressions, not defaults, correct? (I would
consider the latter to mean t
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Plus, the fact that we don't support "default" specifications in
> pl/pgsql for row types turns this inconvenience into a major PITA,
You mean initialization expressions, not defaults, correct? (I would
consider the latter to mean that whatever att
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
I just stumbled over the following behaviour, introduced with 8.3,
and wondered if this is by design or an oversight.
No, this was in 8.2.
Ah, sorry - I'm porting an app from 8.1 straight to 8.3, and blindly
assumes that i'd have
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Joshua D. Drake wrote:
I would also question the 64KB at a time. Why not a 1024KB (arbitrary)
at a time? Is it a resource issue? In the old days when we actually
had people trying to run postgresql on 128 and 256 megs of ram, o.k.
but
Andrew Dunstan wrote:
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
We read 64 KB at a time, and then CopyReadLineText returns one line
at a time from that buffer.
O.k. I am sure I am oversimplifying things but why are we returning
one line at a time? That reads expensive to me. Just
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Joshua D. Drake wrote:
>> I would also question the 64KB at a time. Why not a 1024KB (arbitrary)
>> at a time? Is it a resource issue? In the old days when we actually
>> had people trying to run postgresql on 128 and 256 megs of ram, o.k.
>> but now?
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> What seems worse is that it still fails even if you declare the domain
> to have a default value.
Hmm, that seems like it could be a bug. We don't currently consider
that a rowtype includes the parent table's defaults or constraints.
But if we are goi
Joshua D. Drake wrote:
Heikki Linnakangas wrote:
We read 64 KB at a time, and then CopyReadLineText returns one line
at a time from that buffer.
O.k. I am sure I am oversimplifying things but why are we returning
one line at a time? That reads expensive to me. Just following the
general,
On Saturday 23 February 2008 00:40, Tom Lane wrote:
> Andy Pavlo <[EMAIL PROTECTED]> writes:
> > I have added support in readfuncs.c to write out Query and PlannedStmt
> > objects using nodeToString() and then read them back in. We needed this
> > so that we could use PREPARE and write the argument
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> I just stumbled over the following behaviour, introduced with 8.3, and
> wondered if this is by design or an oversight.
No, this was in 8.2.
> If you define a domain over some existing type, constrain it to
> non-null values, and use that domain as
Tom Lane wrote:
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
At some point, I think we have to bite the bullet and find a way to use
multiple CPUs for a single load. I don't have any good ideas or plans
for that, but hopefully someone does.
As already mentioned upthread, we could do that
Tom Lane wrote:
Greg Smith <[EMAIL PROTECTED]> writes:
On Fri, 22 Feb 2008, Tom Lane wrote:
Counts are useless here, we need to see the sequence of write locations
to find out if there's a lot of nonconsecutive writes happening.
How were you planning to analyze the strace output to quantify
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
On Sun, 24 Feb 2008 00:43:18 +
"Heikki Linnakangas" <[EMAIL PROTECTED]> wrote:
I know that copy is in theory a bulk loader but, when performing the
readline how many lines are we reading? Do we read up to 8192? Or do we
shove in say 8megs
Andrew Dunstan wrote:
Florian G. Pflug wrote:
If you define a domain over some existing type, constrain it to
non-null values, and use that domain as a field type in a table
definition, it seems to be impossible to declare pl/pgsql variables
of that table's row type. The problem seems to be t
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> At some point, I think we have to bite the bullet and find a way to use
> multiple CPUs for a single load. I don't have any good ideas or plans
> for that, but hopefully someone does.
As already mentioned upthread, we could do that today, with z
Florian G. Pflug wrote:
Hi
I just stumbled over the following behaviour, introduced with 8.3, and
wondered if this is by design or an oversight.
If you define a domain over some existing type, constrain it to
non-null values, and use that domain as a field type in a table
definition, it seem
Hi
I just stumbled over the following behaviour, introduced with 8.3, and
wondered if this is by design or an oversight.
If you define a domain over some existing type, constrain it to
non-null values, and use that domain as a field type in a table
definition, it seems to be impossible to decla
Hello,
I found easy implementation of variadic functions. It's based on
adapation FuncnameGetCandidates. When I found variadic function, then
I should create accurate number of last arguments (diff between
pronargs and nargs). Variadic function can be signed via flag or via
some pseudotype. Flag i
Heikki Linnakangas wrote:
Joshua D. Drake wrote:
On Sun, 24 Feb 2008 00:43:18 +
"Heikki Linnakangas" <[EMAIL PROTECTED]> wrote:
Incidentally, I've been working on a patch to speed up CopyReadLine.
I was going to run some more tests first, but since we're talking
about it, I guess I should
On Mon, Feb 11, 2008 at 5:51 PM, Tom Lane wrote:
> I agree. Since any multiple-output-file case can't usefully use stdout,
> I think we should combine the switches and just have one switch that
> says both that you want separated output and what the target filename
> is. Thus something like
>
[This message is mostly for the benefit of the list -- he and I already talked
a bit about this here at FOSDEM. Ishii-san, if you have a chance we should sit
down and talk about this in more detail before we leave!]
Tatsuo Ishii wrote:
>> On Tue, Feb 19, 2008 at 3:36 AM, Tatsuo Ishii <[EMAIL PRO
> On Tue, Feb 19, 2008 at 3:36 AM, Tatsuo Ishii <[EMAIL PROTECTED]> wrote:
> > We propose to implement the recursive query (WITH RECURSIVE clause)
> > defined in SQL:1999 and later. With the recursive query, one can
> > easily inquire the data expressed as tree and graph structures. The
> > ac
Heikki Linnakangas wrote:
I don't see any piece of code that's causing problems.
Meant to say: I don't see any *single* piece of code that's causing the
problems...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)
Joshua D. Drake wrote:
On Sun, 24 Feb 2008 00:43:18 +
"Heikki Linnakangas" <[EMAIL PROTECTED]> wrote:
Incidentally, I've been working on a patch to speed up CopyReadLine.
I was going to run some more tests first, but since we're talking
about it, I guess I should just post the patch. I'll
35 matches
Mail list logo
