On Thu, May 5, 2011 at 4:03 AM, Tom Lane wrote:
> Greg Stark writes:
>> Isn't there already some gadget which forces postfix operators to be
>> discouraged compared to some other interpretation in other cases?
>
> Yeah. I'm not unhappy with the current grammar's behavior in this case.
> What's b
Greg Stark writes:
> Isn't there already some gadget which forces postfix operators to be
> discouraged compared to some other interpretation in other cases?
Yeah. I'm not unhappy with the current grammar's behavior in this case.
What's bothering me is that the implementation seems likely to cre
Oops. This should have been posted to pgpool-hackers. Sorry for noise.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
> Hi,
>
> I have just committed changes to enhance online recovery in streaming
> replication mode. Pgpool-II
Hi,
I have just committed changes to enhance online recovery in streaming
replication mode. Pgpool-II had to restart child process to recognize
failback node. Now pgpool-II becomes a little bit smarter and does not
need to restart children. This means that client sessions started
before online rec
While running some benchmarks to test SSI performance, I found a race
condition that's capable of causing a segfault. A patch is attached.
The bug is in CheckTargetForConflictsIn, which scans the list of SIREAD
locks on a lock target when it's modified. There's an optimization in
there where the w
On Thu, May 5, 2011 at 12:39 AM, Tom Lane wrote:
>
> So I'd still like to get rid of the precedence markings for TRUE_P,
> FALSE_P, and UNKNOWN, and will do so unless somebody has a really good
> reason not to. (It looks like we could avoid marking ZONE, too.) But
> I would be happier if we coul
Alvaro Herrera writes:
> As a followup idea there exists the desire to store records as records
> and not text representation of same (given differing record types, of
> course), for which it'd be more worthwhile.
Maybe. The conventional wisdom is that text representation of data is
more compact
Andrew Dunstan writes:
> On 05/04/2011 07:39 PM, Tom Lane wrote:
>> If you try the experiment, you find out that the first interpretation is
>> preferred by the current grammar:
>> ERROR: operator does not exist: integer %% unknown
> Yeah, IIRC the default action for a shift/reduce conflict is t
Excerpts from Tom Lane's message of mié may 04 20:05:54 -0300 2011:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of mié may 04 14:36:44 -0300 2011:
> >> Just out of curiosity, what actual functionality gain would ensue over
> >> just using text? It seems like doing anything usefu
On 05/04/2011 07:39 PM, Tom Lane wrote:
While looking at the grammar's operator-precedence declarations in
connection with a recent pgsql-docs question, it struck me that this
declaration is a foot-gun waiting to go off:
%nonassoc IS NULL_P TRUE_P FALSE_P UNKNOWN /* sets precedence for I
"David E. Wheeler" writes:
> On May 4, 2011, at 3:04 PM, Alvaro Herrera wrote:
>> As someone commented downthread, they also want to have things such as a
>> "typeof" operator. It could be used in (say) a plpgsql function to
>> choose different branches of code.
> FWIW, pg_typeof(any) has been i
While looking at the grammar's operator-precedence declarations in
connection with a recent pgsql-docs question, it struck me that this
declaration is a foot-gun waiting to go off:
%nonassoc IS NULL_P TRUE_P FALSE_P UNKNOWN /* sets precedence for IS
NULL, etc */
The only terminal that we a
On 05/04/2011 07:05 PM, Tom Lane wrote:
Alvaro Herrera writes:
Excerpts from Tom Lane's message of mié may 04 14:36:44 -0300 2011:
Just out of curiosity, what actual functionality gain would ensue over
just using text? It seems like doing anything useful with the audit
table contents would
On May 4, 2011, at 3:04 PM, Alvaro Herrera wrote:
> As someone commented downthread, they also want to have things such as a
> "typeof" operator. It could be used in (say) a plpgsql function to
> choose different branches of code.
FWIW, pg_typeof(any) has been in core since 9.0.
Best,
David
On Wed, 04 May 2011 15:11:57 -, Andrew Dunstan
wrote:
On 05/04/2011 01:25 AM, Johann 'Myrkraverk' Oskarsson wrote:
On Tue, 03 May 2011 12:40:28 -, Andrew Dunstan
wrote:
Our Makefiles use dlltool and dllwrap to create DLLs. If you used our
recommended build method pgxs would do
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié may 04 14:36:44 -0300 2011:
>> Just out of curiosity, what actual functionality gain would ensue over
>> just using text? It seems like doing anything useful with the audit
>> table contents would still require casting the column t
Excerpts from Tom Lane's message of mié may 04 14:36:44 -0300 2011:
> Alvaro Herrera writes:
> > The main idea is to be able to store column values in an audit table
> > like this:
> > old_valuevariant
> > new_valuevariant
> > Currently, they use text for old_value and new_value, but this
I wrote:
> On the other hand, as a shop where we're probably going to set
> default_transaction_isolation = serializable in our
> postgresql.conf files and include trigger checks that we're
> running at that level, we can just boost those globally. That may
> also work for others.
Just as a qu
On Wed, May 4, 2011 at 3:47 AM, Tom Lane wrote:
> Jaime Casanova writes:
>> I want to propose the addition of a new field in IDENTIFY_SYSTEM:
>> xlogversion, which will carry XLOG_PAGE_MAGIC from primary.
>> The idea of sending that info is to allow us to know if the xlog page
>> version of two d
On Wed, May 4, 2011 at 2:55 PM, Andrew Dunstan wrote:
> On 05/04/2011 01:36 PM, Tom Lane wrote:
>>
>>> The main idea is to be able to store column values in an audit table
>>> like this:
>>> old_value variant
>>> new_value variant
>>> Currently, they use text for old_value and new_valu
During studying of existing GiST code I have a question.
gistFindCorrectParent function have branch with following comment:
/*
* awful!!, we need search tree to find parent ... , but before we
* should release all old parent
*/
Can you provide me an example of case when this branch works?
Robert Haas writes:
> ... One of the big, fat problems
> with typispreferred is that it totally falls apart when more than two
> types are involved. For example, given a call f(int2), we can't
> decide between f(int4) and f(int8), but it seems pretty clear (to me,
> at least) that we should prefe
Robert Haas wrote:
> On Tue, May 3, 2011 at 10:07 PM, Kevin Grittner
> wrote:
>> ... on a toy table with contrived values. How different is this
>> from the often-asked question about why a query against a
>> four-line table is not using the index they expect, and how can
>> we expect it to scal
On Tue, May 3, 2011 at 10:07 PM, Kevin Grittner
wrote:
> ... on a toy table with contrived values. How different is this
> from the often-asked question about why a query against a four-line
> table is not using the index they expect, and how can we expect it
> to scale if it doesn't? I agree th
On 05/04/2011 01:36 PM, Tom Lane wrote:
The main idea is to be able to store column values in an audit table
like this:
old_value variant
new_value variant
Currently, they use text for old_value and new_value, but this is, of
course, not very satisfactory.
Just out of curiosity,
On Tue, May 3, 2011 at 3:06 PM, Tom Lane wrote:
> I wrote:
>> Alvaro Herrera writes:
>>> The interesting discussion is what happens next. To me, this is all
>>> related to this previous discussion:
>>> http://archives.postgresql.org/pgsql-hackers/2010-09/msg00232.php
>
>> Yeah, there doesn't see
On Wed, May 4, 2011 at 21:09, Peter Eisentraut wrote:
> On ons, 2011-05-04 at 20:32 +0200, Magnus Hagander wrote:
>> Is this part really correct?
>>
>> - fprintf(stderr, _("%s: final receive failed: %s\n"),
>> + fprintf(stderr, _("%s: final receive failed: %s"),
>>
>> all other msgs ha
On ons, 2011-05-04 at 20:32 +0200, Magnus Hagander wrote:
> Is this part really correct?
>
> - fprintf(stderr, _("%s: final receive failed: %s\n"),
> + fprintf(stderr, _("%s: final receive failed: %s"),
>
> all other msgs have \n.. I see you removed the final dot in many of
> the othe
Josh Berkus writes:
> On 5/4/11 11:29 AM, Tom Lane wrote:
>> If you can't change the app, I'd suggest more aggressive autovacuuming
>> as the least painful fix.
> Will test that. It's not clear that vacuuming is helping at all.
Well, you realize of course that you need a REINDEX to get the inde
On 5/4/11 11:29 AM, Tom Lane wrote:
> which is up in the same ballpark with your problem. Now probably your
> client's app is not updating all rows at once, but still this is a
> pretty wasteful update pattern. Is there a reason not to update all
> the columns in a single update?
Yeah, really cr
On Wed, May 4, 2011 at 12:36 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> A customer came to us with this request: a way to store "any" data in a
>> column. We've gone back and forth trying to determine reasonable
>> implementation restrictions, safety and useful semantics for them.
>
> Yes,
Alvaro Herrera wrote:
A customer came to us with this request: a way to store "any" data in a
column. We've gone back and forth trying to determine reasonable
implementation restrictions, safety and useful semantics for them.
I note that this has been requested in the past:
http://archives.postg
Peter Eisentraut writes:
> On mån, 2011-04-25 at 19:18 -0400, Tom Lane wrote:
>> Hm, does that mean we have consensus on treating it as an error?
> Regarding the patch you committed: I would avoid hardcoding
> "postgresql.conf" in error or hint messages, since we don't know whether
> that's the
Josh Berkus writes:
>> Can you provide the data in the column that's indexed?
> Attached. This is for the index which is 90% free space.
I tried loading this data in fresh, and then creating a gist__intbig_ops
index on it. I got these pgstattuple numbers (in 8.4.8):
table_len | 88064
On mån, 2011-04-25 at 19:18 -0400, Tom Lane wrote:
> Hm, does that mean we have consensus on treating it as an error?
Regarding the patch you committed: I would avoid hardcoding
"postgresql.conf" in error or hint messages, since we don't know whether
that's the actual name of the file. No other m
Josh Berkus writes:
> (c) we *think* that other columns of the table, including other indexed
> columns, are changed much more frequently than the intarray column is.
> Currently doing analysis on that.
Yeah, I noticed that your statistics for the table showed far more
updates than insertions or
Alvaro Herrera writes:
> A customer came to us with this request: a way to store "any" data in a
> column. We've gone back and forth trying to determine reasonable
> implementation restrictions, safety and useful semantics for them.
Yes, it seems rather messy.
> The main idea is to be able to s
On Wed, May 4, 2011 at 1:21 PM, Josh Berkus wrote:
>
>>> You can't indent patches, only patched files. And that's the problem
>>> with this happy scheme. For it to work at all sanely we'd need to keep
>>> the committed code that the patch is to be applied against strictly
>>> pgindent clean, presu
On Wed, May 4, 2011 at 19:21, Josh Berkus wrote:
>
>>> You can't indent patches, only patched files. And that's the problem
>>> with this happy scheme. For it to work at all sanely we'd need to keep
>>> the committed code that the patch is to be applied against strictly
>>> pgindent clean, presuma
>> You can't indent patches, only patched files. And that's the problem
>> with this happy scheme. For it to work at all sanely we'd need to keep
>> the committed code that the patch is to be applied against strictly
>> pgindent clean, presumably via some automated process such as a commit
>>
Alvaro Herrera wrote:
> A customer came to us with this request: a way to store "any" data
> in a column.
+1
More than once (usually in replication, interface, or audit
situations) I've had to create a table with one column each of a
number of different data types, only one of which will be
All,
I thought that Dimitri had already implemented this using Fincore. It's
linux-only, but that should work well enough to test the general concept.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Hello,
A customer came to us with this request: a way to store "any" data in a
column. We've gone back and forth trying to determine reasonable
implementation restrictions, safety and useful semantics for them.
I note that this has been requested in the past:
http://archives.postgresql.org/pgsql-
On Wed, May 4, 2011 at 7:10 AM, Mitsuru IWASAKI wrote:
> Hi,
>
> I am working on new feature `Buffer Cache Hibernation' which enables
> postgres to keep higher cache hit ratio even just started.
>
> Postgres usually starts with ZERO buffer cache. By saving the buffer
> cache data structure into h
Alvaro Herrera wrote:
As for gain, I have heard of test setups requiring hours of runtime in
order to prime the buffer cache.
And production ones too. I have multiple customers where a server
restart is almost a planned multi-hour downtime. The system may be back
up, but for a couple of
On Wed, May 4, 2011 at 4:44 PM, Tom Lane wrote:
> Do you have
> any proof that writing out a few GB of buffers and then reading them
> back in is actually much cheaper than letting the database re-read the
> data from the disk files?
I believe he's just writing out the meta data. Ie, which blocks
Hey folks,
I'd kind of like to get this issue nailed down soon so I can update the PGXN
HOWTO and illustrate a generally agreed-upon best practice for extension
developers. How *do* we want people to use versions in their extension?
Thanks,
David
On Apr 28, 2011, at 2:16 PM, David E. Wheeler
Hitoshi Harada writes:
> I sometimes wonder if we could pull up aggregate query in the optimizer.
I don't have time to look at this right now, but please add to the
upcoming commitfest.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o
2011/5/4 Greg Stark :
> On Wed, May 4, 2011 at 3:10 PM, Mitsuru IWASAKI
> wrote:
>> Postgres usually starts with ZERO buffer cache. By saving the buffer
>> cache data structure into hibernation files just before shutdown, and
>> loading them at startup, postgres can start operations with the sav
On Tue, May 3, 2011 at 6:46 PM, Tian Luo wrote:
> Hi guys,
>
> No matter I turn on or turn off the "full_page_writes", I always
> observe 8192-byte writes of log data for simple write operations
> (write/update).
>
> But according to the document, when this is off, it could speed up
> operations b
Excerpts from Tom Lane's message of mié may 04 12:44:36 -0300 2011:
> This seems like a lot of complication for rather dubious gain. What
> happens when the DBA changes the shared_buffers setting, for instance?
> How do you protect against the cached buffers getting out-of-sync with
> the actual
Mitsuru IWASAKI writes:
> Postgres usually starts with ZERO buffer cache. By saving the buffer
> cache data structure into hibernation files just before shutdown, and
> loading them at startup, postgres can start operations with the saved
> buffer cache as the same condition as just before the la
On Wed, May 4, 2011 at 3:10 PM, Mitsuru IWASAKI wrote:
> Postgres usually starts with ZERO buffer cache. By saving the buffer
> cache data structure into hibernation files just before shutdown, and
> loading them at startup, postgres can start operations with the saved
> buffer cache as the same
On 05/04/2011 10:10 AM, Mitsuru IWASAKI wrote:
Hi,
I am working on new feature `Buffer Cache Hibernation' which enables
postgres to keep higher cache hit ratio even just started.
Postgres usually starts with ZERO buffer cache. By saving the buffer
cache data structure into hibernation files
Alexander Korotkov writes:
> I have another hypothesis about index bloat cause. AFAIK, vaccum procedure
> on GiST don't have any storage utilization guarantee. For example, if only
> one live item is in some page, then only one item will be left in this page.
> I.e. there is no index reroganizatio
On 05/04/2011 01:25 AM, Johann 'Myrkraverk' Oskarsson wrote:
On Tue, 03 May 2011 12:40:28 -, Andrew Dunstan
wrote:
Our Makefiles use dlltool and dllwrap to create DLLs. If you used our
recommended build method pgxs would do lots of the work for you.
I'm not sure why you asked the ming
Hi,
I am working on new feature `Buffer Cache Hibernation' which enables
postgres to keep higher cache hit ratio even just started.
Postgres usually starts with ZERO buffer cache. By saving the buffer
cache data structure into hibernation files just before shutdown, and
loading them at startup,
On Wed, May 4, 2011 at 12:19 AM, Tom Lane wrote:
> Mind you, I've read more than enough horribly-formatted patches to wish
> that we could do something about this. But I doubt that a mechanical
> reformatting pass before reviewing will be a net plus.
It wouldn't hurt to have the option.
It woul
Jim Nasby writes:
> Which begs the question... why do we allow on assignment casting of a float
> to an int?
Because the SQL standard requires it.
In any case, the user's intent in such a case is perfectly clear.
The reasons for not allowing assignment casts to happen in expression
contexts are
On May 4, 2011, at 12:00 AM, Зотов Роман wrote:
>>> F(smallint)
>>> F(integer)
>>> but call like F(float)
>>> i wouldn`t like to fail it.
>> I think this particular example would be a mistake, because that cast
>> would be lossy, so you want to invoke it only when the user explicitely
>> selects it
On May 3, 2011, at 11:10 PM, Andrew Dunstan wrote:
> On 05/03/2011 09:53 PM, David Blewett wrote:
>> On Tue, May 3, 2011 at 9:51 PM, David Blewett wrote:
>>> This seems like a pretty good idea, but maybe it'd be easiest to take
>>> it a step further and add an "automatic pgindent-ified" patch is
>
On Wed, May 4, 2011 at 5:46 PM, Pavan Deolasee wrote:
>
>
> On Wed, May 4, 2011 at 7:16 AM, Tian Luo wrote:
>
>> Hi guys,
>>
>> No matter I turn on or turn off the "full_page_writes", I always
>> observe 8192-byte writes of log data for simple write operations
>> (write/update).
>>
>>
> Not sure
On Wed, May 4, 2011 at 7:16 AM, Tian Luo wrote:
> Hi guys,
>
> No matter I turn on or turn off the "full_page_writes", I always
> observe 8192-byte writes of log data for simple write operations
> (write/update).
>
>
Not sure how you measured it, but ISTM that the correct GUC to play with is
"fsy
Hi,
On 05/04/2011 03:46 AM, Tian Luo wrote:
> No matter I turn on or turn off the "full_page_writes", I always
> observe 8192-byte writes of log data for simple write operations
> (write/update).
How did you measure that? A single transaction doing a single write, I
guess. Ever tried multiple t
> Greg Smith wrote:
> My point was just that no one has really done that here yet:
> provided an example showing SSI serialization working as a
> substitute for predicate locking in this sort of use case. I trust
> that the theory is sound here, and yet I'd still like to see that
> demonstrated.
I sometimes wonder if we could pull up aggregate query in the optimizer.
My typical problem is:
Consider two relations, medium size M and large size L. L has
reference column to M's primary key. Say,
create table size_m as select i as id, repeat(i::text, i % 100) as
val from generate_series(
I have another hypothesis about index bloat cause. AFAIK, vaccum procedure
on GiST don't have any storage utilization guarantee. For example, if only
one live item is in some page, then only one item will be left in this page.
I.e. there is no index reroganization during vacuum. If there wouldn't b
67 matches
Mail list logo
