Den 4 Dec 2010 kl. 08:48 skrev Heikki Linnakangas
heikki.linnakan...@enterprisedb.com:
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.
On 04.12.2010 10:22, jes...@krogh.cc wrote:
Den 4 Dec 2010 kl. 08:48 skrev Heikki
Linnakangasheikki.linnakan...@enterprisedb.com:
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
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 at A+1
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:
On Dec 4, 2010, at 1:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ross J. Reedstrom reeds...@rice.edu 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
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
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
Itagaki Takahiro itagaki.takah...@gmail.com 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?
On Wed, Dec 1, 2010 at 3:05 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Dec 4, 2010 at 6:48 AM, Robert Haas robertmh...@gmail.com wrote:
On Dec 4, 2010, at 1:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Ross J. Reedstrom reeds...@rice.edu writes:
If you consider that an index basically is, in some sense, a pre-canned
column list, then:
ALTER TABLE
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:
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 version.
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() here
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
Robert Treat r...@xzilla.net 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
Greg Stark gsst...@mit.edu writes:
On Wed, Dec 1, 2010 at 3:05 PM, Tom Lane t...@sss.pgh.pa.us 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
Peter Eisentraut pete...@gmx.net 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
On 12/04/2010 11:56 AM, Tom Lane wrote:
Greg Starkgsst...@mit.edu 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
Andrew Dunstan and...@dunslane.net 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
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
Tom Lane t...@sss.pgh.pa.us 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
On Sat, Dec 4, 2010 at 6:07 PM, Oleg Bartunov o...@sai.msu.su 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
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
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
Andrew Dunstan and...@dunslane.net 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
On Sat, Dec 04, 2010 at 12:19:59PM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
On Dec 4, 2010, at 11:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Treat r...@xzilla.net 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
Greg Stark gsst...@mit.edu 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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Greg Stark gsst...@mit.edu 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
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
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]
On Dec 4, 2010, at 1:22 PM, Dimitri Fontaine dimi...@2ndquadrant.fr
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
On Wed, Dec 1, 2010 at 6:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 30, 2010 at 11:32 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On 11/28/10, Robert Haas robertmh...@gmail.com wrote:
In a close race, I don't think we should get bogged down in
micro-optimization here, both
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 kevin.gritt...@wicourts.gov wrote:
Vaibhav Kaushal wrote:
I want to parallelize the search / scan (specifically hash) by
using multiple cores in the processors today.
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
On Sun, Dec 5, 2010 at 07:24, Andrew Dunstan and...@dunslane.net 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
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
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
38 matches
Mail list logo
