On 12/06/10 01:16, Josh Berkus wrote:
Well, we're already not waiting for fsync, which is the slowest part.
If there's a performance problem, it may be because FADVISE_DONTNEED
disables kernel buffering so that we're forced to actually read the data
back from disk before sending it on down the
On 13/06/10 15:28, Mohammad Heykal Abdillah wrote:
After i read PostgreSQL documentation, i found that pg_attribute contain
"attrelid" that reference to pg_class oid. But after i look to
"/src/include/catalog/pg_class.h" there is no member named "oid".
This what i trying to acomplish using "heap
After i read PostgreSQL documentation, i found that pg_attribute contain
"attrelid" that reference to pg_class oid. But after i look to
"/src/include/catalog/pg_class.h" there is no member named "oid".
This what i trying to acomplish using "heap_getnext" function:
if (((Form_pg_class) GETSTRUCT(h
Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of jue jun 10 11:46:25 -0400 2010:
>
> > Yes, the folks at commandprompt need to be told about this. Loudly.
> > It's a serious packaging error.
>
> Just notified Lacey, the packager (not so loudly, though); she's working
> on new packages
Dimitri Fontaine writes:
> Also, should I try to send a patch implementing my proposal (internal
> command exposed as a function at the SQL level, and while at it, maybe
> the internal command "pg_archive_bypass" to mimic /usr/bin/true as an
> archive_command)?
I had to have a try at it, even if
Dimitri Fontaine writes:
> Heikki Linnakangas writes:
>> So to clean up all WAL files older than those needed by that base backup,
>> you would simply copy-paste that location and call pg_cleanuparchive:
>>
>> pg_cleanuparchive /walarchive/ 0001002F
>
> Ok, idle though: what about
On Jun 12, 2010, at 10:21 AM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> Which, IIRC, is new in 9.1, so could in theory be removed, especially if
>> there was an
>>hstore(text[], text[])
>
> Oh --- now that I look, both that and the hstore => text[] one are new
> in 9.0, which mean
Tom Lane wrote:
> I notice that in 8.4 and before, the function underlying text => text
> wasn't called hstore() but tconvert(). Which is going to be a serious
> PITA for anyone who wants to write cross-version-compatible SQL using
> hstore. Can we do anything about this? I don't think we want t
Jan Urba??ski wrote:
> Hi,
>
> per $SUBJECT.
Applied.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
"David E. Wheeler" writes:
> Which, IIRC, is new in 9.1, so could in theory be removed, especially if
> there was an
> hstore(text[], text[])
Oh --- now that I look, both that and the hstore => text[] one are new
in 9.0, which means it is not too late to reverse course. So at this
point
Greg Stark wrote:
> On Sat, Jun 12, 2010 at 4:58 AM, Bruce Momjian wrote:
> > However, I might have been too conservative. ?How do tools that generate
> > multiple output files usually handle this situation? ?Do they output in
> > to a subdirectory in $HOME, or in a subdirectory of the current
> >
"David E. Wheeler" writes:
> On Jun 11, 2010, at 2:23 PM, Tom Lane wrote:
>>> hstore(key := 'this', key2 := 'that')
>>> hstore(key => 'this', key2 => 'that')
>>> hstore(row('this' AS key, 'that' AS key2))
>>
>> The last of those is probably the easiest to get to. We already have
>> hstore_from_r
Bruce Momjian writes:
> I think we might need two bits, one commited and all visible, and
> another aborted and all vislble.
Huh? The latter means "vacuumable".
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
On Jun 12, 2010, at 7:15 AM, Florian Pflug wrote:
>> It's reasonable to say that the first two are bad design, but I'm
>> a bit less willing to say that the last one is. What shall we
>> do with that?
>
> Hm, the last one seems to be more akin to
>hstore - textyields hstore (key
On Jun 11, 2010, at 2:23 PM, Tom Lane wrote:
>> hstore(key := 'this', key2 := 'that')
>> hstore(key => 'this', key2 => 'that')
>> hstore(row('this' AS key, 'that' AS key2))
>
> The last of those is probably the easiest to get to. We already have
> hstore_from_record:
Is not the first one simply
Greg Stark wrote:
> On Thu, Jun 3, 2010 at 11:41 AM, Greg Stark wrote:
> > I think to make it work you need to store a whole 64-bit reference
> > transaction id consisting of both a cycle counter and a transaction
> > id. The invariant for the page is that every xid on the page can be
> > compared
Hi
To be able to asses the performance characteristics of the different
wal-related options, I patched pgbench to show the average latency of each
individual statement. The idea is to be able to compare the latency of the
COMMIT with the ones of the other statements.
This patch adds two new fi
On Jun 12, 2010, at 14:57 , Tom Lane wrote:
> But actually, there's another issue here: hstore defines not one but
> three => operators:
>
> text => textyields hstore (with 1 element)
> text[] => text[]yields hstore (with N elements)
> hstore => text[]
Peter Eisentraut writes:
> On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote:
>> But a reference would be a datatype no? So we could just regard that as
>> an ordinary operator. I don't see a reason why it would conflict with
>> use of the same operator name for other datatypes (unlike the situa
On Jun 12, 2010, at 3:10 , Josh Berkus wrote:
>> Hm, but then Robert's failure case is real, and streaming replication might
>> break due to an OS-level crash of the master. Or am I missing something?
>
> 1) Master goes out
> 2) "floating" transaction applied to standby.
> 3) Standby goes out
> 4
On Sat, Jun 12, 2010 at 4:58 AM, Bruce Momjian wrote:
> However, I might have been too conservative. How do tools that generate
> multiple output files usually handle this situation? Do they output in
> to a subdirectory in $HOME, or in a subdirectory of the current
> directory, or just create m
On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> >>> Btw., the SQL standard also defines -> for something else, so if you
> >>> wanted to be really visionary, you could deprecate that one as an
> >>> operator at the same time.
> >>
> >> Ouch. What does it define it
22 matches
Mail list logo
