On Tue, Oct 8, 2013 at 6:46 PM, Andres Freund wrote:
> On 2013-10-08 15:07:02 +0530, Pavan Deolasee wrote:
>> On Tue, Oct 8, 2013 at 2:33 PM, Sawada Masahiko wrote:
>>
>> > On Fri, Oct 4, 2013 at 4:32 PM, Fujii Masao wrote:
>> > >
>> > I attached the v12 patch which have modified based on above s
On Tue, Oct 8, 2013 at 6:37 PM, Pavan Deolasee wrote:
>
> On Tue, Oct 8, 2013 at 2:33 PM, Sawada Masahiko
> wrote:
>>
>> On Fri, Oct 4, 2013 at 4:32 PM, Fujii Masao wrote:
>> >
>> I attached the v12 patch which have modified based on above suggestions.
>
>
> There are still some parts of this de
On Wed, Oct 9, 2013 at 10:44 AM, Peter Eisentraut wrote:
> On Thu, 2013-10-03 at 17:50 +0530, Jeevan Chalke wrote:
> > Will you please attach new patch with above block removed ? Then I
> > will quickly check that new patch and mark as "Ready For Committer".
> >
> Here you go.
>
>
Thanks Peter. P
On Thu, 2013-10-03 at 17:50 +0530, Jeevan Chalke wrote:
> Will you please attach new patch with above block removed ? Then I
> will quickly check that new patch and mark as "Ready For Committer".
>
Here you go.
From ba421c778cc3f7c32886ac038389cfbad3c0df67 Mon Sep 17 00:00:00 2001
From: Peter Eis
Where did this patch come from?
I think part of that patch should be reverted, but I can't find the
original submission for the rationale.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacke
On Wed, Oct 9, 2013 at 5:26 AM, Robert Haas wrote:
> On Mon, Oct 7, 2013 at 4:47 PM, Andres Freund
> wrote:
> > On 2013-10-07 13:25:17 -0400, Robert Haas wrote:
> >> On Fri, Oct 4, 2013 at 8:19 AM, Andres Freund
> wrote:
> >> > Could it be that MAXALIGN/TYPEALIGN doesn't really work for values
Hi,
In the release notes for 9.2.5,
Should the following:
"Fix rare GROUP BY query error caused by improperly processed date
type modifiers (Tom Lane)"
be:
"Fix rare GROUP BY query error caused by improperly processed *data*
type modifiers (Tom Lane)"
Assuming the change has to do with the fo
On Tue, Oct 8, 2013 at 6:03 PM, Andrew Dunstan wrote:
>
> On 10/07/2013 11:34 PM, Amit Kapila wrote:
>>
>> On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan
>> wrote:
>>>
>>> On 10/07/2013 03:06 PM, Robert Haas wrote:
> Also if your use case is to treat empty strings as NULL (as per a
On Tue, Oct 08, 2013 at 03:40:04PM -0400, Robert Haas wrote:
> On Thu, Sep 26, 2013 at 9:27 AM, Noah Misch wrote:
> >> > "There's no data corruption problem if we proceed" - but there likely
> >> > has been one leading to the current state.
> >
> > +1 for making this one a PANIC, though. With st
On 8.10.2013 21:59, Heikki Linnakangas wrote:
> On 08.10.2013 17:47, Alexander Korotkov wrote:
>> Hi, Tomas!
>>
>> On Sun, Oct 6, 2013 at 3:58 AM, Tomas Vondra wrote:
>>
>>> I've attempted to rerun the benchmarks tests I did a few weeks ago, but
>>> I got repeated crashes when loading the data (
On Tue, Oct 8, 2013 at 01:04:18PM -0600, Kevin Hale Boyes wrote:
> The patch contains a small typo in config.sgml. Probably just drop the "is"
> from "is can".
>
> +results if this database cluster is can utilize most of the memory
>
> Kevin.
Thank you, fixed.
--
Bruce Momjian
2013/10/9 Andrew Dunstan :
>
> On 10/08/2013 12:47 PM, Andrew Dunstan wrote:
>>
>>
>> On 10/08/2013 12:30 PM, Robert Haas wrote:
>>>
>>> Andrew, are you planning to review & commit this?
>>>
>>
>> Yes.
>>
>>
>
> Incidentally, the patch doesn't seem to add the option to file_fdw, which I
> really th
On 2013-10-08 12:26:17 -0400, Robert Haas wrote:
> On Mon, Oct 7, 2013 at 4:47 PM, Andres Freund wrote:
> > So I guess it's either a separate macro, or we rewrite that piece of
> > code to work slightly differently and work directly on the lenght or
> > such.
> >
> > Maybe we should add a StaticAs
Kevin Grittner wrote:
> [ isolation test failed at snapshot-based isolation levels ]
Fix pushed, that looks for the right results based on isolation level.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hacke
On 2013-10-08 15:40:04 -0400, Robert Haas wrote:
> I am tempted to commit the latest version of this patch as I have it.
I haven't looked at the latest version of the patch, but based on the
previous version I have no problem with that.
If you'd feel more comfortable with another round of review,
On 08.10.2013 17:47, Alexander Korotkov wrote:
Hi, Tomas!
On Sun, Oct 6, 2013 at 3:58 AM, Tomas Vondra wrote:
I've attempted to rerun the benchmarks tests I did a few weeks ago, but
I got repeated crashes when loading the data (into a table with
tsvector+gin index).
Right before a crash, t
On 2013-10-08 12:20:22 -0400, Robert Haas wrote:
> On Mon, Oct 7, 2013 at 9:32 AM, Andres Freund wrote:
> >> - RelationIsDoingTimetravel is still a crappy name. How about
> >> RelationRequiredForLogicalDecoding? And maybe the reloption
> >> treat_as_catalog_table can become required_for_logical_
On Thu, Sep 26, 2013 at 9:27 AM, Noah Misch wrote:
>> > "There's no data corruption problem if we proceed" - but there likely
>> > has been one leading to the current state.
>
> +1 for making this one a PANIC, though. With startup behind us, a valid dsm
> state file pointed us to a control segmen
On 2013-10-08 15:02:39 -0400, Steve Singer wrote:
> On 10/07/2013 09:32 AM, Andres Freund wrote:
> >Todo:
> >* rename treat_as_catalog_table, after agreeing on the new name
> >* rename remaining timetravel function names
> >* restrict SuspendDecodingSnapshots usage to RelationInitPhysicalAddr,
> >
Although I asked this question, I've reconsidered about these parameters, and it
seems that these parameters not only make code rather complex but are a little
confusing to users. So I'd like to propose to introduce only one parameter:
fast_cache_size. While users that give weight to update pe
The patch contains a small typo in config.sgml. Probably just drop the
"is" from "is can".
+results if this database cluster is can utilize most of the memory
Kevin.
On 8 October 2013 10:13, Bruce Momjian wrote:
> On Thu, Sep 5, 2013 at 05:14:37PM -0400, Bruce Momjian wrote:
> > On
On 10/07/2013 09:32 AM, Andres Freund wrote:
Todo:
* rename treat_as_catalog_table, after agreeing on the new name
* rename remaining timetravel function names
* restrict SuspendDecodingSnapshots usage to RelationInitPhysicalAddr,
that ought to be enough.
* add InLogicalDecoding() function.
*
On Oct 8, 2013 6:27 PM, "Robert Haas" wrote:
>
> On Mon, Oct 7, 2013 at 7:51 AM, Andrew Dunstan
> wrote:
> > Given that we have not supported releases older than 8.3 for quite a
while,
> > do we need to keep this in extend.sgml any longer?
>
> +1 for removing that (but only in master, not the bac
On 04.10.2013 14:13, Alexander Korotkov wrote:
On Fri, Oct 4, 2013 at 12:28 PM, Heikki Linnakangas
wrote:
In the attached patch, I in fact already did that for data leaf pages, but
didn't change the format of non-leaf pages yet. If we want to support
pg_upgrade, we might want to refrain from c
On 10/08/2013 12:47 PM, Andrew Dunstan wrote:
On 10/08/2013 12:30 PM, Robert Haas wrote:
Andrew, are you planning to review & commit this?
Yes.
Incidentally, the patch doesn't seem to add the option to file_fdw,
which I really think it should.
cheers
andrew
--
Sent via pgsql-hack
Bruce Momjian escribió:
> On Tue, Oct 8, 2013 at 02:25:25PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian escribió:
> >
> > > Do we need to update any version or anything? I didn't think so.
> >
> > I think there should be an 1.1 version here. That way, if somebody is
> > using the existing d
On Tue, Oct 8, 2013 at 02:25:25PM -0300, Alvaro Herrera wrote:
> Bruce Momjian escribió:
>
> > Do we need to update any version or anything? I didn't think so.
>
> I think there should be an 1.1 version here. That way, if somebody is
> using the existing definition from the 1.0 module, they ca
Bruce Momjian escribió:
> Do we need to update any version or anything? I didn't think so.
I think there should be an 1.1 version here. That way, if somebody is
using the existing definition from the 1.0 module, they can get the new
definition by doing an extension upgrade.
--
Álvaro Herrera
On Tuesday 08 October 2013 12:28:46 Robert Haas wrote:
> On Mon, Oct 7, 2013 at 12:32 PM, Marc Cousin wrote:
> > I was using the lo contrib a few days ago and wasn't paying attention, and
> > forgot the "for each row" in the create trigger command... PostgreSQL
> > segfaulted, when the trigger tri
2013/10/8 Bruce Momjian
> On Tue, Oct 8, 2013 at 06:38:30PM +0200, Pavel Stehule wrote:
> > I am not sure - does pg_upgrade change of flag after upgrade without
> increasing
> > version number?
>
> What happens in pg_upgrade is that the CREATE EXTENSION command is
> pg_dump'ed, and run by pg_upr
On 10/08/2013 12:30 PM, Robert Haas wrote:
On Tue, Oct 8, 2013 at 8:33 AM, Andrew Dunstan wrote:
On 10/07/2013 11:34 PM, Amit Kapila wrote:
On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan
wrote:
On 10/07/2013 03:06 PM, Robert Haas wrote:
Also if your use case is to treat empty strings as N
On Tue, Oct 8, 2013 at 06:38:30PM +0200, Pavel Stehule wrote:
> I am not sure - does pg_upgrade change of flag after upgrade without
> increasing
> version number?
What happens in pg_upgrade is that the CREATE EXTENSION command is
pg_dump'ed, and run by pg_uprade, and it then pulls from the SQL
On Mon, Oct 7, 2013 at 12:32 PM, Marc Cousin wrote:
> I was using the lo contrib a few days ago and wasn't paying attention, and
> forgot the "for each row" in the create trigger command... PostgreSQL
> segfaulted, when the trigger tried to access the row's attributes.
>
> Please find attached a p
2013/10/8 Bruce Momjian
> On Tue, Oct 8, 2013 at 06:31:03PM +0200, Pavel Stehule wrote:
> >
> >
> >
> > 2013/10/8 Bruce Momjian
> >
> > On Tue, Sep 24, 2013 at 05:36:58PM -0400, Bruce Momjian wrote:
> > > On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
> > > > On Sat, S
On Tue, Oct 8, 2013 at 06:31:03PM +0200, Pavel Stehule wrote:
>
>
>
> 2013/10/8 Bruce Momjian
>
> On Tue, Sep 24, 2013 at 05:36:58PM -0400, Bruce Momjian wrote:
> > On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
> > > On Sat, Sep 14, 2013 at 9:42 AM, Pavel Stehule
>
2013/10/8 Bruce Momjian
> On Tue, Sep 24, 2013 at 05:36:58PM -0400, Bruce Momjian wrote:
> > On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
> > > On Sat, Sep 14, 2013 at 9:42 AM, Pavel Stehule <
> pavel.steh...@gmail.com> wrote:
> > > >> I have developed the attached patch based on
On Tue, Oct 8, 2013 at 8:33 AM, Andrew Dunstan wrote:
> On 10/07/2013 11:34 PM, Amit Kapila wrote:
>> On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan
>> wrote:
>>> On 10/07/2013 03:06 PM, Robert Haas wrote:
> Also if your use case is to treat empty strings as NULL (as per above
> document
The commit below, specifically the change mentioned in the last paragraph
to fix isLockedRel broke the following comment in addRangeTableEntry:
* If pstate is NULL, we just build an RTE and return it without adding it
* to an rtable list.
In fact isLockedRefname() will seg fault promptly if pst
On Mon, Oct 7, 2013 at 7:51 AM, Andrew Dunstan
wrote:
> Given that we have not supported releases older than 8.3 for quite a while,
> do we need to keep this in extend.sgml any longer?
+1 for removing that (but only in master, not the back-branches).
--
Robert Haas
EnterpriseDB: http://www.ente
On Mon, Oct 7, 2013 at 4:47 PM, Andres Freund wrote:
> On 2013-10-07 13:25:17 -0400, Robert Haas wrote:
>> On Fri, Oct 4, 2013 at 8:19 AM, Andres Freund wrote:
>> > Could it be that MAXALIGN/TYPEALIGN doesn't really work for values
>> > bigger than 32bit?
>> >
>> > #define MAXALIGN(LEN)
On Tue, Sep 24, 2013 at 05:36:58PM -0400, Bruce Momjian wrote:
> On Tue, Sep 17, 2013 at 10:15:47AM -0400, Robert Haas wrote:
> > On Sat, Sep 14, 2013 at 9:42 AM, Pavel Stehule
> > wrote:
> > >> I have developed the attached patch based on your suggestion. I did not
> > >> see anything in the co
On Mon, Oct 7, 2013 at 9:32 AM, Andres Freund wrote:
>> - RelationIsDoingTimetravel is still a crappy name. How about
>> RelationRequiredForLogicalDecoding? And maybe the reloption
>> treat_as_catalog_table can become required_for_logical_decoding.
>
> Hm. I don't really like the name, required
On Thu, Sep 5, 2013 at 05:14:37PM -0400, Bruce Momjian wrote:
> On Thu, Sep 5, 2013 at 06:14:33PM +0200, Magnus Hagander wrote:
> > > I have developed the attached patch which implements an auto-tuned
> > > effective_cache_size which is 4x the size of shared buffers. I had to
> > > set effective
*Don't* VACUUM FULL. Just VACUUM. It's not the same thing.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08.10.2013 13:00, Pavan Deolasee wrote:
On Tue, Oct 8, 2013 at 3:16 PM, Andres Freundwrote:
It is my impression that there still are several people having pretty
fundamental doubts about this approach in general. From what I remember
neither Heikki, Simon, Tom nor me were really convinced ab
Hi,
Thanks for your review, sorry about the delays in answering, I've been
quite busy with other matters recently, it seems like things are going
to be smoother this week.
Peter Eisentraut writes:
> Review of the PL/Tcl part: The functionality looks OK. There are some
> cosmetic issues. If th
On 10/08/2013 08:03 AM, shailesh singh wrote:
Dear all,
First of all i wish to share actual error meassge,
Below are the queries i had executed on the terminal on my server
-bash-3.2$ touch fix.sql
-bash-3.2$ echo "VACUUM FULL;" > fix.sql
-bash-3.2$ postgres -D /var/lib/pgsql/data patnadbold
Dear all,
First of all i wish to share actual error meassge,
Below are the queries i had executed on the terminal on my server
-bash-3.2$ touch fix.sql
-bash-3.2$ echo "VACUUM FULL;" > fix.sql
-bash-3.2$ postgres -D /var/lib/pgsql/data patnadbold < fix.sql
WARNING: database "patnadbold" must be
Hi, Tomas!
On Sun, Oct 6, 2013 at 3:58 AM, Tomas Vondra wrote:
> I've attempted to rerun the benchmarks tests I did a few weeks ago, but
> I got repeated crashes when loading the data (into a table with
> tsvector+gin index).
>
> Right before a crash, theres this message in the log:
>
>PANI
On 8 Říjen 2013, 13:52, Atri Sharma wrote:
> On Tue, Oct 8, 2013 at 4:15 PM, Tomas Vondra wrote:
>> On 8 Říjen 2013, 11:42, Atri Sharma wrote:
I've made some significant improvements in the chaining version (in
the
master branch), now getting about the memory consumption I've
>
On Tue, Oct 8, 2013 at 01:25:30PM +0900, KONDO Mitsumasa wrote:
> (2013/10/08 10:35), Bruce Momjian wrote:
> >docs: update release notes for 8.4.18, 9.0.14, 9.1.10, 9.2.5, 9.3.1
> Thank you for creating good release note. I have one comment.
>
> In 9.1 and 9.2 release note, Is "Improve WAL segme
Heikki Linnakangas wrote:
> On 07.10.2013 23:45, Heikki Linnakangas wrote:
>> To fix the bug that Hannu pointed out, we also need to apply these fixes:
>>
>> http://www.postgresql.org/message-id/52440266.5040...@vmware.com
>
> Per a chat with Bruce, I'm going to apply that patch now to get it int
On 10/07/2013 08:47 PM, Peter Eisentraut wrote:
I suspect this line
submake-libpq: $(libdir)/libpq.so ;
will cause problems on platforms with a different extension (e.g. OS X).
suggested fix is below.
cheers
andrew
diff --git a/src/Makefile.global.in b/src/Makefile.global.in
index bb732
(2013/10/08 20:13), Haribabu kommi wrote:
I chosen the sync_commit=off mode because it generates more tps, thus it
increases the volume of WAL.
I did not think to there. Sorry...
I will test with sync_commit=on mode and provide the test results.
OK. Thanks!
--
Mitsumasa KONDO
NTT Open Sourc
On Tue, Oct 8, 2013 at 05:08:17PM +0530, Rushabh Lathia wrote:
> This
> might be a case where throwing an error is actually better than trying
> to make sense of the input.
>
> I don't feel super-strongly about this, but I offer it as a question
> for reflection.
>
>
>
> At
Hi,
I tested dbt-2 benchmark in single instance and synchronous replication.
Unfortunately, my benchmark results were not seen many differences...
* Test server
Server: HP Proliant DL360 G7
CPU:Xeon E5640 2.66GHz (1P/4C)
Memory: 18GB(PC3-10600R-9)
Disk: 146GB(15k)*4 RAID1+0
On 10/08/2013 03:55 AM, shailesh singh wrote:
I had got this message while running vacuum full from backend . Now My
database is not starting , Help pls.
backend> vacuum full debug;
WARNING: database "debug" must be vacuumed within 99 transactions
HINT: To avoid a database shutdown, execut
On 10/07/2013 11:34 PM, Amit Kapila wrote:
On Tue, Oct 8, 2013 at 12:55 AM, Andrew Dunstan wrote:
On 10/07/2013 03:06 PM, Robert Haas wrote:
Also if your use case is to treat empty strings as NULL (as per above
documentation), can't it be handled with "WITH NULL AS" option.
For example, som
On Sat, Oct 5, 2013 at 6:10 PM, Noah Misch wrote:
The sum of the squares of the latencies wraps after 2^63/(10^12 * avg_latency
* nclients) seconds. That's unlikely to come up with the ordinary pgbench
script, but one can reach it in a few hours when benchmarking a command that
runs for many
On Tue, Oct 8, 2013 at 4:15 PM, Tomas Vondra wrote:
> On 8 Říjen 2013, 11:42, Atri Sharma wrote:
>>>
>>> I've made some significant improvements in the chaining version (in the
>>> master branch), now getting about the memory consumption I've estimated.
>>>
>> I agree, we can hope to reduce the me
On Tue, Oct 8, 2013 at 1:34 AM, Robert Haas wrote:
> On Mon, Oct 7, 2013 at 12:41 AM, Rushabh Lathia
> wrote:
> > Hmm right it has some inconsistency when year length is 6. But the patch
> > is based on assumption that 5-digit number is a year, because YMD and HMS
> > require at least six digits
On 08 October 2013 15:22 KONDO Mitsumasa wrote:
> (2013/10/08 17:33), Haribabu kommi wrote:
>> The checkpoint_timeout and checkpoint_segments are increased to make sure no
>> checkpoint happens during the test run.
>Your setting is easy occurred checkpoint in checkpoint_segments = 256. I don't
>
I had got this message while running vacuum full from backend . Now My
database is not starting , Help pls.
backend> vacuum full debug;
WARNING: database "debug" must be vacuumed within 99 transactions
HINT: To avoid a database shutdown, execute a full-database VACUUM in
"debug".
ERROR: rel
On 8 Říjen 2013, 11:42, Atri Sharma wrote:
>>
>> I've made some significant improvements in the chaining version (in the
>> master branch), now getting about the memory consumption I've estimated.
>>
> I agree, we can hope to reduce the memory consumption by making changes in
> the current chaining
On Tue, Oct 8, 2013 at 3:16 PM, Andres Freund wrote:
>
>
> It is my impression that there still are several people having pretty
> fundamental doubts about this approach in general. From what I remember
> neither Heikki, Simon, Tom nor me were really convinced about this
> approach.
>
>
IIRC you a
On 2013-09-11 12:43:21 +0200, Andres Freund wrote:
> On 2013-09-11 19:39:14 +0900, Fujii Masao wrote:
> > * Benchmark
> > pgbench -c 32 -j 4 -T 900 -M prepared
> > scaling factor: 100
> >
> > checkpoint_segments = 1024
> > checkpoint_timeout = 5min
> > (every checkpoint during benchmark
(2013/10/08 17:33), Haribabu kommi wrote:
The checkpoint_timeout and checkpoint_segments are increased to make sure no
checkpoint happens during the test run.
Your setting is easy occurred checkpoint in checkpoint_segments = 256. I don't
know number of disks in your test server, in my test serv
On 2013-10-08 15:07:02 +0530, Pavan Deolasee wrote:
> On Tue, Oct 8, 2013 at 2:33 PM, Sawada Masahiko wrote:
>
> > On Fri, Oct 4, 2013 at 4:32 PM, Fujii Masao wrote:
> > >
> > I attached the v12 patch which have modified based on above suggestions.
> >
>
> There are still some parts of this desi
Sent from my iPad
>
> However I'm unable to make it at least comparable to chaining. The trick
> is that the hash table performs reasonably only until it's ~ 65-70% full,
> it gets really slow after that. So to maintain performance comparable to
> chaining, I'd have to keep the table below this
On 10/7/13 9:46 PM, Robert Haas wrote:
Looks good to me. Committed.
Thanks.
Also huge thanks to Ian for a phenomenal first review. :-)
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
Heikki Linnakangas wrote:
> A comment somewhere would be nice to explain why we're no longer worried
> about confusing an old tuple version with a new tuple in the same slot.
> Not sure where.
For now I counted on the commit message. Perhaps we also want to
add something to the README file?
--
On Tue, Oct 8, 2013 at 2:33 PM, Sawada Masahiko wrote:
> On Fri, Oct 4, 2013 at 4:32 PM, Fujii Masao wrote:
> >
> I attached the v12 patch which have modified based on above suggestions.
>
There are still some parts of this design/patch which I am concerned about.
1. The design clubs synchronou
On 8 Říjen 2013, 6:23, Atri Sharma wrote:
> Hi Tomas,
>
>
>>> Consider the aspects associated with open addressing.Open addressing
>>> can quickly lead to growth in the main table.Also, chaining is a much
>>> cleaner way of collision resolution,IMHO.
>>
>> What do you mean by "growth in the main ta
On Fri, Oct 4, 2013 at 4:32 PM, Fujii Masao wrote:
>
> You added several checks into SyncRepWaitForLSN() so that it can handle both
> synchronous_transfer=data_flush and =commit. This change made the source code
> of the function very complicated, I'm afraid. To simplify the source code,
> what ab
Sent from my iPad
> On 08-Oct-2013, at 10:41, Claudio Freire wrote:
>
> On Tue, Oct 8, 2013 at 1:23 AM, Atri Sharma wrote:
Consider the aspects associated with open addressing.Open addressing
can quickly lead to growth in the main table.Also, chaining is a much
cleaner way of c
***
/home/kgrittn/pg/master/src/test/isolation/expected/drop-index-concurrently-1.out
2013-07-10 14:58:41.641205557 -0500
---
/home/kgrittn/pg/master/src/test/isolation/results/drop-index-concurrently-1.out
2013-10-07 12:20:49.269277851 -0500
***
*** 30,40
id
76 matches
Mail list logo
