04.05.2011 0:00, Alvaro Herrera пишет:
Excerpts from Зотов Роман's message of mar may 03 16:31:31 -0300 2011:
but here we can see problem like
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
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
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
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.
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
On Wed, May 4, 2011 at 7:16 AM, Tian Luo jackro...@gmail.com 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
On Wed, May 4, 2011 at 5:46 PM, Pavan Deolasee pavan.deola...@gmail.comwrote:
On Wed, May 4, 2011 at 7:16 AM, Tian Luo jackro...@gmail.com 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
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 Blewettda...@dawninglight.net wrote:
This seems like a pretty good idea, but maybe it'd be easiest to take
it a step further and add an automatic
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. The other way
Jim Nasby j...@nasby.net 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
On Wed, May 4, 2011 at 12:19 AM, Tom Lane t...@sss.pgh.pa.us 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
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 05/04/2011 01:25 AM, Johann 'Myrkraverk' Oskarsson wrote:
On Tue, 03 May 2011 12:40:28 -, Andrew Dunstan
and...@dunslane.net 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
Alexander Korotkov aekorot...@gmail.com 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
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
On Wed, May 4, 2011 at 3:10 PM, Mitsuru IWASAKI iwas...@jp.freebsd.org 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
Mitsuru IWASAKI iwas...@jp.freebsd.org 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
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
On Tue, May 3, 2011 at 6:46 PM, Tian Luo jackro...@gmail.com 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
2011/5/4 Greg Stark gsst...@mit.edu:
On Wed, May 4, 2011 at 3:10 PM, Mitsuru IWASAKI iwas...@jp.freebsd.org
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
Hitoshi Harada umi.tan...@gmail.com 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
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
On Wed, May 4, 2011 at 4:44 PM, Tom Lane t...@sss.pgh.pa.us 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.
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 7:10 AM, Mitsuru IWASAKI iwas...@jp.freebsd.org 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
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:
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
Alvaro Herrera alvhe...@alvh.no-ip.org 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
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
hook.
On Wed, May 4, 2011 at 19:21, Josh Berkus j...@agliodbs.com 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,
On Wed, May 4, 2011 at 1:21 PM, Josh Berkus j...@agliodbs.com 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,
Alvaro Herrera alvhe...@alvh.no-ip.org 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
Josh Berkus j...@agliodbs.com 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
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
Josh Berkus j...@agliodbs.com 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
Peter Eisentraut pete...@gmx.net 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
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:
On Wed, May 4, 2011 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@alvh.no-ip.org 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
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
Josh Berkus j...@agliodbs.com 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
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 other
On Wed, May 4, 2011 at 21:09, Peter Eisentraut pete...@gmx.net 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
On Tue, May 3, 2011 at 3:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
The interesting discussion is what happens next. To me, this is all
related to this previous discussion:
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 10:07 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
Robert Haas robertmh...@gmail.com wrote:
On Tue, May 3, 2011 at 10:07 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
Robert Haas robertmh...@gmail.com 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)
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?
On Wed, May 4, 2011 at 2:55 PM, Andrew Dunstan and...@dunslane.net 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
On Wed, May 4, 2011 at 3:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova ja...@2ndquadrant.com 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
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 quick
Excerpts from Tom Lane's message of mié may 04 14:36:44 -0300 2011:
Alvaro Herrera alvhe...@alvh.no-ip.org 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
Alvaro Herrera alvhe...@commandprompt.com 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
On Wed, 04 May 2011 15:11:57 -, Andrew Dunstan and...@dunslane.net
wrote:
On 05/04/2011 01:25 AM, Johann 'Myrkraverk' Oskarsson wrote:
On Tue, 03 May 2011 12:40:28 -, Andrew Dunstan
and...@dunslane.net wrote:
Our Makefiles use dlltool and dllwrap to create DLLs. If you used our
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 05/04/2011 07:05 PM, Tom Lane wrote:
Alvaro Herreraalvhe...@commandprompt.com 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
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
David E. Wheeler da...@kineticode.com 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)
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
Excerpts from Tom Lane's message of mié may 04 20:05:54 -0300 2011:
Alvaro Herrera alvhe...@commandprompt.com 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
Andrew Dunstan and...@dunslane.net 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
Alvaro Herrera alvhe...@commandprompt.com 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
On Thu, May 5, 2011 at 12:39 AM, Tom Lane t...@sss.pgh.pa.us 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
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
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
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 had
Greg Stark gsst...@mit.edu 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
On Thu, May 5, 2011 at 4:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu 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
68 matches
Mail list logo
