Greg Stark wrote:
Using sync_file_range you can specify the set of blocks to sync and
then block on them only after some time has passed. But there's no
documentation on how this relates to the I/O scheduler so it's not
clear it would have any effect on the problem.
I believe this is the exact
Craig Ringer wrote:
On 11/24/2010 05:18 AM, Magnus Hagander wrote:
Or you set the handler always, and have the handler only actually
create the dump if the directory exists. That way you can add the
directory and still get a dump from both existing backends and the
postmaster itself without a
On Sun, Dec 5, 2010 at 07:24, Andrew Dunstan wrote:
> Looking at file_parser.c, it seems to be largely taken from copy.c. Wouldn't
> it be better to call those functions, or refactor them so they are callable
> if necessary?
We could export private functions and structs in copy.c,
though details
All,
While I have this machine available I've been trying to run some
performance tests using pgbench and various wal_sync_methods. However,
I seem to be maxing out at the speed of pgbench itself; no matter which
wal_sync_method I use (including "fsync"), it tops out at around 2750 TPS.
Of
Thank you Kevin. I am going to look into it. I still have to learn a lot :)
Regards,
Vaibhav
On 12/4/10, Kevin Grittner wrote:
> Vaibhav Kaushal wrote:
>
>> I want to parallelize the search / scan (specifically hash) by
>> using multiple cores in the processors today.
>
> You might want to revi
On Wed, Dec 1, 2010 at 6:20 AM, Robert Haas wrote:
> On Tue, Nov 30, 2010 at 11:32 PM, Jeff Janes wrote:
>> On 11/28/10, Robert Haas wrote:
>>>
>>> In a close race, I don't think we should get bogged down in
>>> micro-optimization here, both because micro-optimizations may not gain
>>> much and
On Dec 4, 2010, at 1:22 PM, Dimitri Fontaine
> That's calling for a try :)
>
> What about a new index type that follows the partitioning scheme in its
> root pages in a way that allow the locking to occur in a subpart of it,
> rather than for the whole index.
>
> Well, maybe that needs to have
On 11/25/2010 03:12 AM, Shigeru HANADA wrote:
Hi, hackers,
Attached is a patch that adds file_fdw, FDW which reads records from
files on the server side, as a contrib module. This patch is based on
"SQL/MED core functionality" patch.
[SQL/MED - core functionality]
http://archives.postgresql.
On 12/04/2010 12:37 PM, Robert Haas wrote:
What would make sense to me is: create a pk constraint with the sane name as
the existing unique index. If that constraint name already exists, error.
+1, agreed. Based on this, the syntax should be obvious.
We'll need to doc what to do in the even
Dimitri Fontaine writes:
> Greg Stark writes:
>> I kind of assumed the natural client for KNN-gist was the tsearch full
>> text search indexes handling sorting by relevance. For example if I
>> search for "Postgres DBA" I should find documents where those words
>> appear adjacent first and docume
Greg Stark writes:
> I kind of assumed the natural client for KNN-gist was the tsearch full
> text search indexes handling sorting by relevance. For example if I
> search for "Postgres DBA" I should find documents where those words
> appear adjacent first and documents where the two words appear f
On Dec 4, 2010, at 11:46 AM, Tom Lane wrote:
> Robert Treat writes:
>> Actually I think I'd even be comfortable with A, either you must name the
>> constraint after the index, or you can leave the constraint name out, and
>> we'll use the index name.
>
> Or we could omit the "CONSTRAINT name" cl
On Sat, Dec 04, 2010 at 12:19:59PM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Those are difficulties, certainly. Are they insurmountable
> > obstacles, though? This is something that has been on the TODO
> > list for ages and I think is very worth doing, if we can.
>
> They're possibly s
Andrew Dunstan writes:
> Anyone can create a branch and publish it. That's the democracy that git
> allows. So if you want it, don't argue for it, just do it.
The showstopper is having a unified plan for what to put in there, for
once, and having -core people (commiters) willing to either put gia
On 2010-12-04 19:22, Dimitri Fontaine wrote:
That's calling for a try :)
What about a new index type that follows the partitioning scheme in its
root pages in a way that allow the locking to occur in a subpart of it,
rather than for the whole index.
Would that (global) index be totally ordered?
On 12/04/2010 01:22 PM, Dimitri Fontaine wrote:
Given such an agenda, I'd argue for a feature branch being open for
partitioning so that incremental reviewed work can happen there until we
have enough pieces to consider merging into HEAD.
Anyone can create a branch and publish it. That's t
On Sat, Dec 4, 2010 at 6:07 PM, Oleg Bartunov wrote:
> We'll sync contrib/btree_gist with current API. Also, we're thinking
> about distance for ltree, boxes, circles. I'm not sure about polygons,
> though.
> So, we'll have rather complete set of knn-fied data types.
I kind of assumed the natural
Tom Lane writes:
> partitioning. I have a feeling that the feature will languish on the
> TODO list forever, unless someone comes up with a brilliant idea to
> avoid the problems. As is, the return on investment to do it just
> isn't there.
That's calling for a try :)
What about a new index ty
Thanks to all for patience !
We'll sync contrib/btree_gist with current API. Also, we're thinking
about distance for ltree, boxes, circles. I'm not sure about polygons, though.
So, we'll have rather complete set of knn-fied data types.
Oleg
On Sat, 4 Dec 2010, Tom Lane wrote:
Robert Haas writ
Andrew Dunstan writes:
> Those are difficulties, certainly. Are they insurmountable obstacles,
> though? This is something that has been on the TODO list for ages and I
> think is very worth doing, if we can.
They're possibly surmountable with enough effort, though I think in
reality what you'd
On 12/04/2010 11:56 AM, Tom Lane wrote:
Greg Stark writes:
[ suggestion for cross-table indexes ]
That's been proposed before, and shot down before, though I don't recall
all the reasons offhand. One obvious problem is VACUUM, which assumes
that you can't have two processes trying to vacuu
Peter Eisentraut writes:
> Is there a reason why there are two spaces after the first colon in
> "Sort Method: %s %s: %ldkB\n"
> Is the second part (Disk/Memory) considered part of the sort method?
I think of it as a separate field that we cram onto the same line (in
the textual output for
Greg Stark writes:
> On Wed, Dec 1, 2010 at 3:05 PM, Tom Lane wrote:
>> Perhaps I should have said "possibly workable proposal". What you wrote
>> doesn't even begin to cover the interesting part of the problem, namely
>> how to ensure uniqueness is preserved in the face of concurrent
>> inserti
Robert Treat writes:
> Actually I think I'd even be comfortable with A, either you must name the
> constraint after the index, or you can leave the constraint name out, and
> we'll use the index name.
Or we could omit the "CONSTRAINT name" clause from the syntax
altogether.
I think that allowing
Is there a reason why there are two spaces after the first colon in
"Sort Method: %s %s: %ldkB\n"
Is the second part (Disk/Memory) considered part of the sort method?
The original commit for that is d2a4a406.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On ons, 2010-11-24 at 22:22 +0200, Peter Eisentraut wrote:
> On mån, 2010-11-22 at 11:58 +0900, Itagaki Takahiro wrote:
> > * Did you see any performance regression by collation?
> > I found a bug in lc_collate_is_c(); result >= 0 should be
> > checked before any other checks. SearchSysCache1() her
On tor, 2010-11-18 at 21:37 +0200, Heikki Linnakangas wrote:
> On 15.11.2010 21:42, Peter Eisentraut wrote:
> > On mån, 2010-11-15 at 11:34 +0100, Pavel Stehule wrote:
> >> I am checking a patch. I found a problem with initdb
> >
> > Ah, late night brain farts, it appears. Here is a corrected vers
Vaibhav Kaushal wrote:
> I want to parallelize the search / scan (specifically hash) by
> using multiple cores in the processors today.
You might want to review the efforts of Markus Wanner, who submitted
a series of patches intended to move things in that direction to a
recent CommitFest:
h
On Sat, Dec 4, 2010 at 6:48 AM, Robert Haas wrote:
> On Dec 4, 2010, at 1:30 AM, Tom Lane wrote:
> > "Ross J. Reedstrom" writes:
> >> If you consider that an index basically is, in some sense, a pre-canned
> >> column list, then:
> >
> >> ALTER TABLE table_name ADD PRIMARY KEY (column_list);
>
On Wed, Dec 1, 2010 at 3:05 PM, Tom Lane wrote:
> Perhaps I should have said "possibly workable proposal". What you wrote
> doesn't even begin to cover the interesting part of the problem, namely
> how to ensure uniqueness is preserved in the face of concurrent
> insertions.
I think it wouldn't
Itagaki Takahiro writes:
> The VARIADIC version doesn't hide the 3-args version. I tested the
> behavior by printf-debug. The planner seems to think the non VARIADIC
> version is the best-matched one when 3 arguments are passed.
Nice! All's left is then the commit, right? :)
Regards,
--
Dimitri
Hi,
Thanks for the review, that's quite one! :)
I'm not sure to follow you all along, it seems like the reading is "try
it first then understand and comment again", so sometimes I'm not sure
if you're saying that docs are missing the point or that the behaviour
ain't right.
"David E. Wheeler" w
Dear Greg,
I have updated the MERGE patch for two main problems.
1. Support of system attributes in MERGE action expressions.
In old version of MERGE, I use the top join as the only RTE in var name
space, during the transformation process in parser. It contains all the
common attributes of so
On Dec 4, 2010, at 1:30 AM, Tom Lane wrote:
> "Ross J. Reedstrom" writes:
>> If you consider that an index basically is, in some sense, a pre-canned
>> column list, then:
>
>> ALTER TABLE table_name ADD PRIMARY KEY (column_list);
>> ALTER TABLE table_name ADD PRIMARY KEY USING index_name;
>
>>
On 2010-12-03 20:49, Ana Carolina Brito de Almeida wrote:
We add a simple case study (sourceforge page):
http://sourceforge.net/projects/hypotheticalind/files/TUTORIAL_8_4.pdf/download
Great, thanks!
I'll try to write a bit more about it later:
http://pqxx.org/development/libpqxx/wiki/Hypoth
>> My imagination is probably not as good, but if you at time A wallog the
>> complete map and at A+1 you update a tuple so the visibility bit is cleared
>> but the map bit change does not happen due to a crash. Then at wal replay
>> time you restore the map from time A and if the tuple change a
On 04.12.2010 10:22, jes...@krogh.cc wrote:
Den 4 Dec 2010 kl. 08:48 skrev Heikki
Linnakangas:
If you WAL-log the visibility map changes after-the-fact, it doesn't solve the
race condition we're struggling with: the visibility map change might hit the
disk before the PD_ALL_VISIBLE to the hea
Den 4 Dec 2010 kl. 08:48 skrev Heikki Linnakangas
:
> On 04.12.2010 09:14, jes...@krogh.cc wrote:
>> There has been a lot discussion about index-only scans and how to make the
>> visibillity map crash safe. Then followed by a good discussion about hint
>> bits.
>>
>> What seems to be the main
38 matches
Mail list logo
