On Wed, Nov 13, 2013 at 7:23 PM, Amit Kapila wrote:
> On Wed, Nov 13, 2013 at 4:05 PM, Haribabu kommi
> wrote:
>> On 01 October 2013 00:56 Amit Kapila wrote:
>>> On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut
>>> wrote:
>>> > On 9/28/13 3:05 AM, Amit Kapila wrote:
>>> >> Now as we have an agr
Hi,
Here's a small patch which should speedup json out functions a little bit
by removing a call to strlen for which could be a long string.
The length of the string is already known by the StringInfoData, so there's
no point in letting cstring_to_text() loop over the whole string again.
Regards
On Thu, Nov 14, 2013 at 3:02 PM, Sawada Masahiko wrote:
> I attached patch adds new wal_level 'all'.
> If wal_level is set 'all', the server logs WAL not only when wal_level
> is set 'hot_standby' ,but also when updating hint bit.
> That is, we will be able to know all of the changed block number
Amit Kapila writes:
> Any objections for adding this idea/patch to CF?
You should certainly add it to the CF. You've listed lots of matters
for review, but that's no reason to not get it in the queue to be
reviewed.
regards, tom lane
--
Sent via pgsql-hackers mailing
I have gone through the mail chain of this thread and tried to find
the different concerns or open ends for this patch.
Summarisation of the discussion and concerns for this patch:
1. Security concern in interface
2. Security concern in Windows implementation
3. Handling of Ctrl-C/SIGTERM
4. Seco
> Tatsuo Ishii writes:
>> I am struggling to understand what following phrase says:
>
>> tcp_keepalives_idle (integer)
>> Specifies the number of seconds before sending a keepalive packet
>> on an otherwise idle connection.
>
> It means "the connection is idle except for keepalive packet
Hi all,
I attached patch adds new wal_level 'all'.
If wal_level is set 'all', the server logs WAL not only when wal_level
is set 'hot_standby' ,but also when updating hint bit.
That is, we will be able to know all of the changed block number by
reading the WALs.
This wal_level is infrastructure fo
Tatsuo Ishii writes:
> I am struggling to understand what following phrase says:
> tcp_keepalives_idle (integer)
> Specifies the number of seconds before sending a keepalive packet
> on an otherwise idle connection.
It means "the connection is idle except for keepalive packets".
We could
Hi,
I am struggling to understand what following phrase says:
tcp_keepalives_idle (integer)
Specifies the number of seconds before sending a keepalive packet
on an otherwise idle connection.
What I am not sure is the meaning of "otherwise". Can I safely replace
it to:
Specifies the n
Shigeru Hanada writes:
> I'd like to propose adding inheritance support for foriegn tables.
> David Fetter mentioned this feature last July, but it seems stalled.
> http://www.postgresql.org/message-id/20130719005601.ga5...@fetter.org
The discussion there pointed out that not enough considerati
Hi hackers,
I'd like to propose adding inheritance support for foriegn tables.
David Fetter mentioned this feature last July, but it seems stalled.
http://www.postgresql.org/message-id/20130719005601.ga5...@fetter.org
Supporting inheritance by foreign tables allows us to distribute query
to
On Wed, 2013-10-09 at 18:57 +0200, Pavel Stehule wrote:
> here is a patch for RAISE WHEN clause
Your patch needs to be rebased.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, 2013-11-08 at 10:01 -0500, Nigel Heron wrote:
> here's v4 of the patch. I added documentation and a new global view
> called "pg_stat_socket" (includes bytes_sent, bytes_received and
> stats_reset time)
Your patch needs to be rebased:
CONFLICT (content): Merge conflict in src/test/regress
On Wed, 2013-11-13 at 17:25 +0900, Kyotaro HORIGUCHI wrote:
> Added explicit cast there and rebased to current master.
> Checked no new warning by this patch.
> make check succeeded at both $(src) and $(src)/src/test.
This patch also has whitespace errors detected by git diff --check.
--
Sent
On Tue, 2013-11-12 at 17:48 +0900, Kyotaro HORIGUCHI wrote:
> Hello, this is the revised patch.
Since you're using git, please check your patch for trailing whitespace
with git diff --check.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscri
On Wed, Nov 13, 2013 at 3:42 AM, Peter Eisentraut wrote:
> When an external recovery command such as restore_command or
> archive_cleanup_command fails, it just reports "return code 34567" or
> something, but we have facilities to do decode this properly, so use
> them.
I think this is a very goo
Tatsuo Ishii writes:
> BTW, same characters are assigned different code points are pretty
> common in many character sets (Unicode, for example).
This is widely considered a security bug; read section 10 in RFC 3629 (the
definition of UTF8), and search the CVE database a bit if you still doubt
it
Reminder: Commit fest 2013-11, the third commit fest (out of four) in
the PostgreSQL development cycle, will start this Friday, November 15.
If you have a patch that you would like to see considered for inclusion
into PostgreSQL 9.4, please register it in the commit fest application
before Friday:
Iy
On Thu, Nov 14, 2013 at 3:51 AM, Mika Eloranta wrote:
> Prevent excessive progress reporting that can grow to gigabytes
> of output with large databases.
It might be interesting to add this patch to the next commit fest
where you could get a formal review:
https://commitfest.postgresql.org/act
On Nov 13, 2013, at 4:45 PM, Andrew Dunstan wrote:
>> It should be a pretty-printing function option, perhaps, but not core to the
>> type itself, IMO.
>
> I don't in the least understand how it could be a pretty printing option. If
> we move to a binary rep using the hstore stuff order will b
On 11/13/2013 07:39 PM, David E. Wheeler wrote:
On Nov 13, 2013, at 2:41 PM, Gavin Flower wrote:
Would be possible to have a boolean, such as 'strict' - so that unique &
ordered was only imposed when strict was TRUE? Alternately, separate functions to
allow the same choice?
It should be a
> Tatsuo Ishii writes:
>>> MULE is completely evil.
>>> It has N different encodings for the same character,
>
>> What's wrong with that? It aims that in the first place.
>
> It greatly complicates comparisons --- at least, if you'd like to preserve
> the principle that strings that appear the s
On 11/13/2013 07:01 PM, Hannu Krosing wrote:
I guess we should not replace current JSON type with hstore based
one, but add something json-like based on nested hstore instead.
Well, that's two voices for that course of action.
Interesting that I don't think I heard a single voice for this e
On Nov 13, 2013, at 2:41 PM, Gavin Flower wrote:
> Would be possible to have a boolean, such as 'strict' - so that unique &
> ordered was only imposed when strict was TRUE? Alternately, separate
> functions to allow the same choice?
It should be a pretty-printing function option, perhaps, but
On Nov 13, 2013, at 3:59 PM, Hannu Krosing wrote:
> I remember strong voices in support of *not* normalising json, so that
> things like
>
> {"a":1,"a":true, "a":"b", "a":none}
>
> would go through the system unaltered, for claimed standard usage of
> json as
> "processing instructions". That i
Snowman --
Thanks for feedback. I imagined this feature could be useful in a couple
of contexts, though mainly in the sense of documenting query optimization
efforts.
In one case you may be tweaking cost parameters and having a built in
record of the parameters in the explain output can make tha
Tatsuo Ishii writes:
>> MULE is completely evil.
>> It has N different encodings for the same character,
> What's wrong with that? It aims that in the first place.
It greatly complicates comparisons --- at least, if you'd like to preserve
the principle that strings that appear the same are equal
> MULE is completely evil.
> It has N different encodings for the same
> character,
What's wrong with that? It aims that in the first place.
> not to mention no support code available.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.c
Stephen Frost wrote
> * Robert Berry (
> berrydigital@
> ) wrote:
>> This is my first attempt at writing a patch, so it's pretty simple.
>
> Neat!
>
>> seq_page: 1.00, rnd_page: 4.00, cpu_tup: 0.01,
>> cpu_ind: 0.005000, cpu_op: 0.002500
>> amenabled: 1
* Robert Berry (berrydigi...@gmail.com) wrote:
> This is my first attempt at writing a patch, so it's pretty simple.
Neat!
> seq_page: 1.00, rnd_page: 4.00, cpu_tup: 0.01,
> cpu_ind: 0.005000, cpu_op: 0.002500
> amenabled: 111
>
> The bit vector
On 11/14/2013 12:09 AM, Merlin Moncure wrote:
> On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus wrote:
>> On 11/13/2013 06:45 AM, Merlin Moncure wrote:> I'm not so sure we should
>> require hstore to do things like build
>>> Also, json_object is pretty weird to me, I'm not sure I see the
>>> advantag
On 11/13/2013 01:37 AM, Andrew Dunstan wrote:
>
> On 11/12/2013 01:35 PM, Teodor Sigaev wrote:
>> Hi!
>>
>> Attatched patch adds nesting feature, types (string, boll and numeric
>> values), arrays and scalar to hstore type.
>>
>> All new features are described in PGConf.EU talk
>> http://www.sai.ms
This is my first attempt at writing a patch, so it's pretty simple.
Commit log sums it up:
Adds a convenience feature to the explain command which prints out GUC cost
parameters in explain text output.
For example:
explain (params) select * from table;
will include text output like
handyrep@john:~/handyrep$ pg_isready --version
pg_isready (PostgreSQL) 9.3.1
handyrep@john:~/handyrep$ pg_isready -h john -p 5432 -U postgres -d
postgres -q
pg_isready: missing "=" after "postgres" in connection info string
handyrep@john:~/handyrep$ pg_isready --host=john --port=5432
--user=post
Merlin,
> I use pg/JSON all over the place. In several cases I have to create
> documents with ordered keys because the parser on the other side wants
> them that way -- this is not a hypothetical argument. The current
> json serialization API handles that just fine and the hstore stuff
> comin
On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus wrote:
>
> > Putting it all together, I'd consider:
> > *) dropping json_object (although maybe there is a case I'm not
> thinking about)
> > *) changing json_build function names to get the json prefix
> > *) adding a json object constructor that t
On Wed, Nov 13, 2013 at 4:16 PM, Josh Berkus wrote:
> On 11/13/2013 06:45 AM, Merlin Moncure wrote:> I'm not so sure we should
> require hstore to do things like build
>> Also, json_object is pretty weird to me, I'm not sure I see the
>> advantage of a new serialization format, and I don't agree w
> Isn't this essentially what the MULE internal encoding is?
No. MULE is not powerfull enough and overly complicated to deal with
different encodings (character sets).
>> Currently there's no such an universal encoding in the universe, I
>> think the only way is, inventing it by ourselves.
>
> T
On 14/11/13 11:33, Andrew Dunstan wrote:
On 11/13/2013 04:58 PM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan
wrote:
On 11/13/2013 11:37 AM, Merlin Moncure wrote:
Yes. and I think this is one of the major advantages of the json API
vs hstore: you can serialize objec
On 11/13/2013 04:58 PM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan wrote:
On 11/13/2013 11:37 AM, Merlin Moncure wrote:
Yes. and I think this is one of the major advantages of the json API
vs hstore: you can serialize objects that hstore cannot -- at least
not with
On 11/13/2013 06:45 AM, Merlin Moncure wrote:> I'm not so sure we should
require hstore to do things like build
> Also, json_object is pretty weird to me, I'm not sure I see the
> advantage of a new serialization format, and I don't agree with the
> statement "but it is the caller's reponsibility t
On Wed, Oct 23, 2013 at 8:52 PM, Alvaro Herrera
wrote:
> Hmm, now if we had portable atomic addition, so that we could spare the
> spinlock ...
That certainly seems like an interesting possibility.
I think that pg_stat_statements should be made to do this kind of
thing by a third party tool that
On 11/9/13, 5:56 AM, Andres Freund wrote:
> ISTM ecpg's regression tests should be built (not run!) during
> $(recurse) not just during make check.
Actually, I did just the opposite change some years ago. The rationale
is, the build builds that which you want to install.
--
Sent via pgsql-hack
On Wed, Nov 13, 2013 at 1:25 PM, Andrew Dunstan wrote:
> On 11/13/2013 11:37 AM, Merlin Moncure wrote:
>>
>> Yes. and I think this is one of the major advantages of the json API
>> vs hstore: you can serialize objects that hstore cannot -- at least
>> not without extra scaffolding (at least, AIUI
As part of doing some database corruption investigation, I'm trying to get the
pg_clog/ bit pair for a particular transaction.
Let's say we check on a particular tuple, and get:
SELECT xmin, id FROM mytable WHERE pk=4727366;
xmin|id
---+--
107898222 | 4727366
E
On 14/11/13 02:45, Peter Eisentraut wrote:
The commit fest manager mace has been passed on to me[*]. More to follow.
[*] Actually, I found it behind the dumpster in the alley.
Did you take care not to touch it with bare skin & properly sterilize
it? As a used mace, may pick up blood from p
Martijn van Oosterhout writes:
> On Tue, Nov 12, 2013 at 03:57:52PM +0900, Tatsuo Ishii wrote:
>> Once we implement the universal encoding, other problem such as
>> "pg_database with multiple encoding problem" can be solved easily.
> Isn't this essentially what the MULE internal encoding is?
MUL
When pg_upgrade generates a rebuild_tsvector_tables.sql script to
rewrite tsvector columns, it includes ALTER TABLE commands for child
tables that cannot be altered independently from their parents:
psql:rebuild_tsvector_tables.sql:673: ERROR: cannot alter inherited column
"xxx"
This isn't a pr
On Tue, Nov 12, 2013 at 03:57:52PM +0900, Tatsuo Ishii wrote:
> I have been thinking about this for years and I think the key idea for
> this is, implementing "universal encoding". The universal encoding
> should have following characteristics to implement N>2 encoding in a
> database.
>
> 1) no l
Robert Haas writes:
> On Tue, Nov 12, 2013 at 11:18 AM, Tom Lane wrote:
>> Or we could say "what the heck are you doing executing tens of
>> thousands of DO blocks? Make it into a real live function;
>> you'll save a lot of cycles on parsing costs." I'm not sure that
>> this is a usage pattern
On 11/12/13, 1:35 PM, Teodor Sigaev wrote:
> Attatched patch adds nesting feature, types (string, boll and numeric
> values), arrays and scalar to hstore type.
Could you check your email client for next time? It's sending
Content-Type: application/x-tar for a *.patch.gz file.
--
Sent via pgsq
On 11/13/2013 11:37 AM, Merlin Moncure wrote:
Yes. and I think this is one of the major advantages of the json API
vs hstore: you can serialize objects that hstore cannot -- at least
not without extra scaffolding (at least, AIUI, I haven't fully
grappled with the coming hstore stuff yet). In
Prevent excessive progress reporting that can grow to gigabytes
of output with large databases.
---
src/bin/pg_basebackup/pg_basebackup.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/src/bin/pg_basebackup/pg_basebackup.c
b/src/bin/pg_basebackup/pg_bas
Kevin Grittner writes:
> If nobody objects, I'll fix that small memory leak in the
> regression test driver. Hopefully someone more familiar with
> pg_basebackup will fix the double-free (and related problems
> mentioned by Tom) in streamutil.c.
Here's a less convoluted (IMHO) approach to the pa
Looks like we got another set of errors overnight. Here's the log file
from the errors. (Log file scrubbed slightly to remove private data,
but still representative of the problem I believe.)
Nov 13 05:34:34 dev postgres[6084]: [4-1] user=dev,db=dev ERROR:
could not access status of transaction 63
On Wed, Nov 13, 2013 at 9:32 AM, Andrew Dunstan wrote:
>> I'm not so sure we should require hstore to do things like build
>> arbitrary json objects even though I agree that hstore will probably
>> displace json for must cases where you want to store nested data (as
>> opposed to (de-)serialize).
On Mon, Nov 11, 2013 at 11:10 PM, Craig Ringer wrote:
> On 11/11/2013 06:37 PM, Kohei KaiGai wrote:
>> I'd like to vote the last options. It is a separate problem (or, might
>> be specification), I think.
>
> I tend to agree, but I'm nervous about entirely hand-waving around this,
> as doing so wo
On 2013-11-12 19:24:39 +0100, Andres Freund wrote:
> On 2013-11-12 13:18:19 -0500, Robert Haas wrote:
> > On Tue, Nov 12, 2013 at 12:50 PM, Andres Freund
> > wrote:
> > > Completely agreed. As evidenced by the fact that the current change
> > > doesn't update all relevant comments & code. I wonde
On Tue, Nov 12, 2013 at 09:55:34AM -0500, Robert Haas wrote:
> On Fri, Nov 8, 2013 at 4:13 PM, Noah Misch wrote:
> > A PANIC will reinitialize everything relevant, largely resolving the
> > problems
> > around ERROR during FATAL. It's a heavy-handed solution, but it may well be
> > the best solu
On Mon, Nov 11, 2013 at 4:34 PM, Andres Freund wrote:
>>I'm pretty sure that the current coding, which blows away the whole
>>relation, is used in other places, and I really don't see why it
>>should be fundamentally flawed, or why we should change it to clear
>>the cache entries out one by one in
Tom Lane wrote:
> No, this isn't about test code vs production, it's about not bothering
> to free memory explicitly when a program is about to terminate. Alvaro
> is suggesting that the proposed addition to pg_regress.c is just a waste
> of cycles. IMO it's not that big a deal either way in th
On 11/13/2013 09:45 AM, Merlin Moncure wrote:
On Wed, Nov 13, 2013 at 1:33 AM, Craig Ringer wrote:
On 11/13/2013 02:34 AM, Andrew Dunstan wrote:
If there's agreement on taking these, I will prepare patches and submit
them by the 15th.
With JSON enhancement, my only concern is that there's wo
Simon Riggs wrote
>> Can you CLUSTER
>> against a minmax index?
>
> Not in this release, at least in my understanding. It's not yet
> possible to do an ordered fetch, so the cluster scan probably won't
> work.
As per the patch I helped writing, CLUSTER should use the
sequential heap scan+sort whe
When pg_upgrade encounters a full disk while copying relation files,
it reports this as:
error while copying relation "xyz" (...): Success
because it doesn't set errno in some error cases. In other places we
treat short writes as ENOSPC, so here is a patch to do that for
pg_upgrade as well.
diff
On Wed, Nov 13, 2013 at 08:58:07AM +0530, Amit Kapila wrote:
> On Tue, Nov 12, 2013 at 9:37 PM, Bruce Momjian wrote:
> > On Wed, Oct 23, 2013 at 10:31:39AM +0530, Amit Kapila wrote:
> >> On Tue, Oct 22, 2013 at 3:04 AM, Piotr Marcinczyk
> >> wrote:
> >> > Hi,
> >> >
> >> > I would like to implem
On Tue, Nov 12, 2013 at 08:39:35PM -0500, Bruce Momjian wrote:
> > My specific wording is incoherent mostly because it really belongs to a
> > larger corpus that currently exists only in my head.
>
> Oh, OK, it sounds fine. The user really doesn't choose what timeline to
> see --- rather, it is t
On 13 November 2013 11:54, Merlin Moncure wrote:
>> Load time
>> MinMax no overhead, same as raw COPY
>> BTree - considerably slower
And just as a general comment, the min max index does not slow down
COPY as the table gets larger, whereas the btree gets slower as the
table gets larger. Which is
On 13 November 2013 11:54, Merlin Moncure wrote:
> On Wed, Nov 13, 2013 at 7:33 AM, Simon Riggs wrote:
>> On 13 November 2013 09:31, Leonardo Francalanci wrote:
>>> I would like to see some numbers.
>>
>> Alvaro has given me some results for his patch. The figures I have are
>> for a 2GB table.
On Wed, Nov 13, 2013 at 7:33 AM, Simon Riggs wrote:
> On 13 November 2013 09:31, Leonardo Francalanci wrote:
>> I would like to see some numbers.
>
> Alvaro has given me some results for his patch. The figures I have are
> for a 2GB table.
>
> Index Build Time
> MinMax 11 s
> Btree 96s
>
> Inde
On Wed, Nov 13, 2013 at 1:33 AM, Craig Ringer wrote:
> On 11/13/2013 02:34 AM, Andrew Dunstan wrote:
>>
>> If there's agreement on taking these, I will prepare patches and submit
>> them by the 15th.
>
> With JSON enhancement, my only concern is that there's work ongoing to
> integrate the v2 deve
Simon Riggs wrote
> From our discussions here, IMHO there is a strong case for avoiding
> btrees completely for larger historical data tables. That isn't
> something I had even considered as desirable before this conversation
> but ISTM now that taking that approach will be more fruitful than
> att
On Wed, Nov 13, 2013 at 10:27 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 11/13/13, 6:18 AM, Sawada Masahiko wrote:
>>> The function of custom script of pgbench allows only BUFSIZ
>>> (i.g.,1024byte) or less as length of a SQL.
>>> So I'm thinking following solution.
>>> (1) to increase
On 11/12/13, 1:57 AM, Tatsuo Ishii wrote:
> Currently there's no such an universal encoding in the universe, I
> think the only way is, inventing it by ourselves.
I think ISO 2022 is something in that direction, but it's not
ASCII-safe, AFAICT.
--
Sent via pgsql-hackers mailing list (pgsql-hack
On 11/13/2013 08:36 AM, Peter Eisentraut wrote:
What exactly is your argument, here?
If we change unused_oids to a Perl implementation, we will add
additional inconvenience to users who don't have /usr/bin/perl in that
exact location. Versus allowing use by users who don't have /bin/sh. I
don
On Wed, Nov 13, 2013 at 4:05 PM, Haribabu kommi
wrote:
> On 01 October 2013 00:56 Amit Kapila wrote:
>> On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut
>> wrote:
>> > On 9/28/13 3:05 AM, Amit Kapila wrote:
>> >> Now as we have an agreement, I had updated patch for below left
>> issues:
>> >
>>
On Wed, Nov 13, 2013 at 8:45 AM, Peter Eisentraut wrote:
> The commit fest manager mace has been passed on to me[*]. More to follow.
>
> [*] Actually, I found it behind the dumpster in the alley.
ROFL.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
The commit fest manager mace has been passed on to me[*]. More to follow.
[*] Actually, I found it behind the dumpster in the alley.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/12/13, 10:48 PM, Andrew Dunstan wrote:
> You quoted me out of context. Your prevuious para referred to
> duplicate_oids.
... which was in turn quoted out of context. ;-)
> What exactly is your argument, here?
If we change unused_oids to a Perl implementation, we will add
additional inconve
On 13 November 2013 09:31, Leonardo Francalanci wrote:
> Or, in other words: what are you going to write in the minmax index
> documentation, "try and see if they work better for you"?
That seems like good advice to me. Bacon > Aristotle.
There is very little written about suitability of any in
Peter Eisentraut writes:
> On 11/13/13, 6:18 AM, Sawada Masahiko wrote:
>> The function of custom script of pgbench allows only BUFSIZ
>> (i.g.,1024byte) or less as length of a SQL.
>> So I'm thinking following solution.
>> (1) to increase buffer size
>> (2) to change to variable buffer size
>> (
On 11/13/13, 6:18 AM, Sawada Masahiko wrote:
> Hi all,
>
> The function of custom script of pgbench allows only BUFSIZ
> (i.g.,1024byte) or less as length of a SQL.
> I think that when we want to bench mark with long SQL then it will difficult.
> At that time even pgbench doesn't return ERROR. I
On 11/11/2013 02:06 PM, Andres Freund wrote:
On 2013-11-10 14:45:17 -0500, Steve Singer wrote:
Not really keen - that'd be a noticeable overhead. Note that in the
cases where DEFAULT|INDEX is used, you can just use the new tuple to
extract what you need for the pkey lookup since they now have th
Jeremy Harris wrote
> Surely there's good correlation between IMSI & IMEI, so have a separate
> table to translate one to (a group of) the others, and
> halve the indexes on your main table?
Yes; unfortunately not always both are available; but it's something
we are thinking about (it requires log
Simon Riggs wrote
> So in the use case you describe, the min max index would require a
> scan of only 25% of the table, not the 80% described earlier for
> random inserts. In my experience, people wish to keep data for much
> longer periods and so the percentage of scan required would drop lower
>
On 12.11.2013 21:33, Teodor Sigaev wrote:
Suppose, some last changes in GIN are broken, 9.3 works fine.
Fixed, thanks for the report.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
On 1 August 2013 01:53, Noah Misch wrote:
> A remediation strategy that seemed attractive when I last contemplated this
> problem is to repoint rd_att immediately but arrange to free the obsolete
> TupleDesc in AtEOXact_RelationCache().
I agree that the best way to resolve this is to retain a co
When an external recovery command such as restore_command or
archive_cleanup_command fails, it just reports "return code 34567" or
something, but we have facilities to do decode this properly, so use
them.
>From 8aa3cf503fe1c1f41a2a833c008f4273c22a86c9 Mon Sep 17 00:00:00 2001
From: Peter Eisentra
On Thu, 2013-11-07 at 19:13 +1300, David Rowley wrote:
> Attached is a small patch which fixes the unused variable warning in
> the visual studios build. Seems like VS does not
> support __attribute__((unused)) but looks like all other places we
> must assign to the variable.
>
committed
--
On 13/11/13 09:07, Leonardo Francalanci wrote:
Problem? having 4 btree indexes on random values (imsi+imei * 2,
since we have calling and caller) kills the performance in insertion
after a while.
Surely there's good correlation between IMSI & IMEI, so have a separate
table to translate one to (
Hi all,
The function of custom script of pgbench allows only BUFSIZ
(i.g.,1024byte) or less as length of a SQL.
I think that when we want to bench mark with long SQL then it will difficult.
At that time even pgbench doesn't return ERROR. It will try to do
query with the broken SQL.
And user can
On Wed, Nov 13, 2013 at 9:00 AM, Andres Freund wrote:
> The old name might not fit there, attribute names have a relatively low
> maximum length (64 by default), so we cannot always fit the entire old
> name there.
Thanks, I was guessing this.
>
> Also, think about:
> CREATE TABLE foo(cola int
On 13.11.2013 11:55, David Rowley wrote:
I thought I would post the patch early to see if this is actually wanted
before I do too much more work on it.
Seems reasonable.
My implementation maintains using the linear list for sequences up to a
defined threshold (currently 32) then it moves ever
On 13 November 2013 06:07, Leonardo Francalanci wrote:
> The use case is pretty simple.
> Think it as the NSA, as it would be much easier.
> Collect all calls made/received by any user on a mobile network.
> (in fact, it's something more than calls, so in fact is 2-10 rows per call).
> Keep the d
On 01 October 2013 00:56 Amit Kapila wrote:
> On Mon, Sep 30, 2013 at 9:07 PM, Peter Eisentraut
> wrote:
> > On 9/28/13 3:05 AM, Amit Kapila wrote:
> >> Now as we have an agreement, I had updated patch for below left
> issues:
> >
> > Regression tests are failing.
>
>Thanks for informing. I a
Here http://www.postgresql.org/message-id/24278.1352922...@sss.pgh.pa.us there
was some talk about init_sequence being a bottleneck when many sequences
are used in a single backend.
The attached I think implements what was talked about in the above link
which for me seems to double the speed of a
Hi,
While looking at the documentation on SELECT I noticed that the
entries in reference.sgml aren't sorted correctly -- psql \h does have
them in the correct order.
Attached a trivial patch to fix this.
In addition, reference.sgml doesn't have entries for TABLE or WITH
which should link to ref/
David et al,
How about something like this?
Cheers,
Colin
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index e603b76..a68014b 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -33,13 +33,14 @@ PostgreSQL documentation
[ WITH [ RECUR
Simon Riggs wrote
> On 5 November 2013 14:28, Leonardo Francalanci <
> m_lists@
> > wrote:
>
>> Either my sql is not correct (likely), or my understanding of the minmax
>> index is
>> not correct (even more likely), or the minmax index is not usable in a
>> random inputs
>> scenario.
>
> Please
2013/11/12 Simon Riggs :
> On 12 November 2013 21:41, Nicolas Barbier wrote:
>
>> Look-up speed is as follows: Each look-up must look through all
>> B-trees.
>
> That can be optimised by using a min max approach, so we need only
> look at sub-trees that may contain data.
Under the assumption tha
On 12 November 2013 19:54, Claudio Freire wrote:
> On Tue, Nov 12, 2013 at 7:14 PM, Simon Riggs wrote:
>> I still think we need to look at this from a query perspective though.
>> We need to check whether there is a class of real world queries that
>> are not well optimised by minmax indexes, or
1 - 100 of 108 matches
Mail list logo
