On 15/03/14 20:27, Heikki Linnakangas wrote:
That said, I didn't expect the difference to be quite that big when
you're appending to the end of the table. When the new entries go to
the end of the posting lists, you only need to recompress and WAL-log
the last posting list, which is max 256 byt
On 14/02/14 00:49, Tom Lane wrote:
Andres Freund writes:
On 2014-02-13 16:15:42 -0500, Tom Lane wrote:
Something like the attached? Can somebody who's seen this problem confirm
this improves matters?
Hm. Won't that possiby lead to the fast tuple list growing unboundedly?
I think we would nee
On 03/02/14 02:44, Tomas Vondra wrote:
(2) The question is whether the new patch works fine on rare words. See
this for comparison of the patches against HEAD:
http://www.fuzzy.cz/tmp/gin/3-rare-words.png
http://www.fuzzy.cz/tmp/gin/3-rare-words-new.png
and this is the c
On 11/10/13 19:06, Andres Freund wrote:
On 2013-10-11 09:22:50 +0530, Amit Kapila wrote:
I think it will be difficult to prove by using any compression
algorithm, that it compresses in most of the scenario's.
In many cases it can so happen that the WAL will also not be reduced
and tps can also c
>
> The really, really big ones are useful even for pushing limits, such
> as cr1.8xlarge, with 32 CPUs and 244GiB memory. Current spot instance
> price (the heavily discounted "can die at any time" one) is $0.343/hr.
> Otherwise, it's 3.500/hr.
>
Just to keep in mind cpus are similar throttled
On 07/06/13 16:39, Tom Lane wrote:
Amit Langote writes:
Okay, aside from that case, what else would move those to the main
structure? They (the entries in the unsorted pending list) are in the
local memory (work_mem?) of the backend, right?
No. If they were, it wouldn't be crash-safe.
Thats
On 12/11/12 05:55, Greg Smith wrote:
The only guarantee I see that we can give for online upgrades is that
after a VACUUM CHECKSUM sweep is done, and every page is known to both
have a valid checksum on it and have its checksum bits set, *then* any
page that doesn't have both set bits and a mat
On 09/11/12 02:01, Jeff Davis wrote:
As I understand it, the main part of the remaining work to be done for
the checksums patch (at least the first commit) is to have a better way
to enable/disable them.
For the sake of simplicity (implementation as well as usability), it
seems like there is agr
> Naturally, there are other compression and delta encoding schemes. Does
> anyone feel the need to explore further alternatives?
>
> We might eventually find the need for multiple, user-selectable, WAL
> compression strategies. I don't recommend taking that step yet.
>
my currently implement
On 08/08/12 21:34, Robert Haas wrote:
I think we need to implement buffering both to end of statement or end
of transaction, not just one or the other.
Another (not necessarily better) idea is to use a buffer that's part
of the index, like the GIN fastupdate stuff, so that there's no
particular
Hi.
First, thanks for looking at this. Except from GIN indexes and
full-text-search being really good in our applications, this also
points to those excact places where it can be improved.
On 2012-02-17 00:15, Tom Lane wrote:
I looked into the complaint here of poor estimation for GIN indexscan
On 2012-02-09 22:17, Jesper Krogh wrote:
On 2012-02-09 21:09, Robert Haas wrote:
That doesn't make sense to me. If you probe index A for rows where a
= 1 and find that CTID (100,1) is such a row, and now want to return a
column value b that is not present in that index, the fastest way t
On 2012-02-09 21:09, Robert Haas wrote:
That doesn't make sense to me. If you probe index A for rows where a
= 1 and find that CTID (100,1) is such a row, and now want to return a
column value b that is not present in that index, the fastest way to
get the row is going to be to fetch block 100 f
On 2012-02-09 18:02, Robert Haas wrote:
I don't have any appetite for trying to do anything more with
index-only scans for 9.2, though maybe someone else will think
otherwise. But I would like very much to get KaiGai's leakproof stuff
committed, and so it seems like a good idea to reconcile the
On 2012-01-29 01:48, Jeff Janes wrote:
I ran three modes, head, head with commit_delay, and the group_commit patch
shared_buffers = 600MB
wal_sync_method=fsync
optionally with:
commit_delay=5
commit_siblings=1
pgbench -i -s40
for clients in 1 5 10 15 20 25 30
pgbench -T 30 -M prepared -c $cli
On 2011-12-22 09:42, Florian Weimer wrote:
* David Fetter:
The issue is that double writes needs a checksum to work by itself,
and page checksums more broadly work better when there are double
writes, obviating the need to have full_page_writes on.
How desirable is it to disable full_page_writ
On 2011-12-19 02:55, Greg Stark wrote:
On Sun, Dec 18, 2011 at 7:51 PM, Jesper Krogh wrote:
I dont know if it would be seen as a "half baked feature".. or similar,
and I dont know if the hint bit problem is solvable at all, but I could
easily imagine checksumming just "skippi
On 2011-12-20 18:44, Simon Riggs wrote:
On Mon, Dec 19, 2011 at 11:10 AM, Simon Riggs wrote:
The only sensible way to handle this is to change the page format as
discussed. IMHO the only sensible way that can happen is if we also
support an online upgrade feature. I will take on the online upg
On 2011-12-19 18:08, Marti Raudsepp wrote:
The query uses the gin index and the tsearch ranking function
ts_rank_cd.
Another thought -- have you read about the GIN "fast updates" feature?
This existed in 9.0 too. Instead of updating the index directly, GIN
appends all changes to a sequential lis
On 2011-12-18 11:19, Heikki Linnakangas wrote:
The patch requires that full page writes be on in order to obviate
this problem by never reading a torn page.
Doesn't help. Hint bit updates are not WAL-logged.
I dont know if it would be seen as a "half baked feature".. or similar,
and I dont kn
On 2011-12-14 19:48, Tom Lane wrote:
Jesper Krogh writes:
On 2011-12-14 19:00, Tom Lane wrote:
So the problem is that we have to either disallow such opclass designs,
or support per-opclass rather than per-index-AM decisions about whether
index-only scans are possible.
Just a quick comment
On 2011-12-14 19:00, Tom Lane wrote:
So the problem is that we have to either disallow such opclass designs,
or support per-opclass rather than per-index-AM decisions about whether
index-only scans are possible.
Just a quick comment, for some queries like the famous
select count(*) from table w
>
>
> So: is there actually any such compression program out there?
> Would anybody really cry if this flag went away?
Perhaps http://pglesslog.projects.postgresql.org/
Jesper
Hi list.
I have currently hit a problem which I dug into finding the cause for, in
particular, searching in GIN indices seems in some situations to
un-fairly favor Sequential Scans.
Googling a bit I found this page:
http://postgis.refractions.net/docs/ch06.html#id2635817
Describing the excact p
Hi List.
This is just an "observation" I'll try to reproduce it in a test set later.
I've been trying to performancetune a database system which does
a lot of updates on GIN indexes. I currently have 24 workers running
executing quite cpu-intensive stored procedures that helps generate
the body
On 2011-08-26 23:02, Tom Lane wrote:
AFAICT this is a red herring: the bug exists all the way back to where
tsvector_concat was added, in 8.3. I think the reason that your test
case happens to not crash before this commit is that it changed the sort
ordering rules for lexemes. As you can see fr
On 2011-08-26 05:28, Tom Lane wrote:
Jesper Krogh writes:
Attached SQL files gives (at least in my hands) a reliable backend crash
with this stacktrace .. reproduced on both 9.0.4 and HEAD. I'm sorry
I cannot provide a more trimmed down set of vectors the reproduces the
bug, thu
Hi
Attached SQL files gives (at least in my hands) a reliable backend crash
with this stacktrace .. reproduced on both 9.0.4 and HEAD. I'm sorry
I cannot provide a more trimmed down set of vectors the reproduces the
bug, thus
the "obsfucated" dataset. But even deleting single terms in the vecto
On 2011-08-08 15:29, Robert Haas wrote:
On Sat, Aug 6, 2011 at 2:16 PM, Dimitri Fontaine wrote:
Robert Haas writes:
It would be nice if the Linux guys would fix this problem for us, but
I'm not sure whether they will. For those who may be curious, the
problem is in generic_file_llseek() in f
On 2011-06-06 09:42, Heikki Linnakangas wrote:
took about 15 hours without the patch, and 2 hours with it. That's
quite dramatic.
With the precense of robust consumer-class SSD-drives that can be
found in sizes where they actually can fit "many" database usage
scenarios. A PostgreSQL version is
On 2011-06-20 22:11, Noah Misch wrote:
On Sun, Jun 19, 2011 at 06:30:41PM +0200, Jesper Krogh wrote:
I hope this hasn't been forgotten. But I cant see it has been committed
or moved
into the commitfest process?
If you're asking about that main patch for $SUBJECT rather
I hope this hasn't been forgotten. But I cant see it has been committed
or moved
into the commitfest process?
Jesper
On 2011-03-11 16:51, Noah Misch wrote:
On Fri, Feb 11, 2011 at 02:13:22AM -0500, Noah Misch wrote:
Automated tests would go a long way toward building confidence that this pat
On 2011-06-15 05:01, Bruce Momjian wrote:
You might remember we added a postmaster/postgres -b switch to indicate
binary upgrade mode. The attached patch prevents any client without an
application_name of 'binary-upgrade' from connecting to the cluster
while it is binary upgrade mode. This help
On 2011-05-11 01:54, Greg Stark wrote:
To be fair about 3/4 of them were actually complaining about the lack
of some global materialized cache of the aggregate value. Covering
index-only scans are only going to be a linear speedup no matter how
large the factor it's not going to turn select count
On 2011-05-10 14:48, Robert Haas wrote:
We could avoid all of this complexity - and the possibility of pinning
the visibility map page needlessly - by locking the heap buffer first
and then pinning the visibility map page if the heap page is
all-visible. However, that would involve holding the l
On 2011-04-25 20:00, Leonardo Francalanci wrote:
> The amount of data loss on a big table will be <1% of the data
> loss caused by truncating the whole table.
If that 1% is random (not time/transaction related), usually you'd
rather have an empty table. In other words: is a table that is not
On 2011-04-18 11:00, Greg Stark wrote:
On Mon, Apr 18, 2011 at 6:25 AM, Jesper Krogh wrote:
Getting the value for the first sortkey and carrying on a closure
for the rest would mostly (very often) be "optimal" ?
Well that might depend. The input data to the function might be much
l
On 2011-04-09 18:54, Tom Lane wrote:
I think that would be a positive disimprovement. The current design
guarantees that volatile sort expressions are evaluated exactly once,
in the order the rows are read from the data source. There would be no
guarantees at all, either as to the number of eva
On 2011-04-11 23:30, Alvaro Herrera wrote:
Excerpts from Jesper Krogh's message of lun abr 11 17:07:33 -0300 2011:
But when the locking is done "row-level" then it is correct
to do it that way. It would allthough be nice with a weaker
locklevel for that kind of updates (I have no clue if that i
On 2011-04-11 20:18, Jesper Krogh wrote:
Hi.
This seem a bit strange to me. In short:
Not any more I.. I guess what made me a bit confused was that
a "update table set key = value" would acually block out changes
on tables referencing this tuple even if the referenced column wasn
Hi.
This seem a bit strange to me. In short:
2 tables, one with has a foreign key to the other one;
CREATE TABLE test (id SERIAL primary key, data text);
CREATE TABLE testref(id SERIAL primary key, test_id integer references
test(id) not null, data text);
INSERT INTO test(data) values('someth
On 2011-04-10 12:18, Oleg Bartunov wrote:
Wow, custom solution for 2008 still much faster Denali 2011 solution.
Also, what's about not spatial data types ? In our approach, we can
provide
knn for any datatype, which has GiST index and distance method.
Can you share some insight about how it
On 2011-04-09 18:54, Tom Lane wrote:
I think that would be a positive disimprovement. The current design
guarantees that volatile sort expressions are evaluated exactly once,
in the order the rows are read from the data source. There would be no
guarantees at all, either as to the number of eval
On 2011-04-09 20:00, David Fetter wrote:
Given the horrors query generators perpetrate, it might be worth
dropping provably redundant ORDER BYs on the floor at planning time.
Well, many people often add a secondary sort-key to their SQL
for the only purpose of obtainting a consistent result in t
>
> How would PostgreSQL know that sorting by id leaves no ambiguity for
> the next key to address?
It wouldn't But it could postpone evaluation until ambiguity was actually
met.
Jesper
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subsc
This seems like a place where there is room for improvement.
2011-04-09 15:18:08.016 testdb=# select id from test1 where id < 3 order
by id;
id
1
2
(2 rows)
Time: 0.328 ms
2011-04-09 15:18:11.936 testdb=# CREATE or Replace FUNCTION testsort(id
integer) returns integer as $$ BEGIN pe
Hi.
I initially set out to put some numbers on "why" the visibillity
map was important for "select count(*)", primarily to give some
feedback to Simon Riggs stating:
"Your tests and discussion remind me that I haven't yet seen any tests
that show that index-only scans would be useful for performa
On 2011-03-22 21:43, Robert Haas wrote:
I took a crack at implementing the first approach described above,
which seems to be by far the simplest idea we've come up with to date.
Patch attached. It doesn't seem to be that complicated, which could
mean either that it's not that complicated or th
On 2011-03-17 15:02, Robert Haas wrote:
On Thu, Mar 17, 2011 at 4:17 AM, Jesper Krogh wrote:
Is it obvious that the visibillity map bits should track complete
pages and not individual tuples? If the visibillity map tracks at
page-level the benefit would fall on "slim tables" where y
Robert Haas wrote:
Right. Really-lazy vacuum could freeze tuples. Unlike regular
vacuum, it can also sensibly be done incrementally. One thing I was
thinking about is counting the number of times that we fetched a tuple
that was older than RecentGlobalXmin and had a committed xmin and an
inval
On 2011-03-10 19:25, Bruce Momjian wrote:
Sure, anyone can add text to that wiki; you create a community account
here:
http://www.postgresql.org/community/signup
Suggestion: Add this url to the login box on the wiki.
--
Jesper
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On 2011-03-10 18:00, Bruce Momjian wrote:
Dirty reads are unlikely to be implemented. We do have a TODO item
and wiki page about how to allow index scans without heap access:
http://wiki.postgresql.org/wiki/Index-only_scans
I think we (the company I work for) would help co-sponsor such
a f
On 2011-02-17 23:20, Tom Lane wrote:
Jesper Krogh writes:
When something evaluates to "null" isn't included in the result,
shouldn't the query-planner
then take the null_frac into account when computing the estimate?
The proposed patch seems wrong to me: if we're e
UERY PLAN
---
Seq Scan on testtable (cost=0.00..2407.03 rows=2470 width=4)
Filter: (testint < 50)
(2 rows)
(found on 8.4 and reproduced on git-head)
Attached patch tries to align the behaviour
Thanks.
--
Jesper
>From 4b4
On 16 Feb 2011, at 23:22, "David E. Wheeler" wrote:
> On Feb 14, 2011, at 11:44 PM, Oleg Bartunov wrote:
>
>>> IMO, sooner or later we need to trash that code and replace it with
>>> something a bit more modification-friendly.
>>
>> We thought about configurable parser, but AFAIR, we didn't get
On 2011-01-24 16:34, Alexander Korotkov wrote:
Hi!
On Mon, Jan 24, 2011 at 3:07 AM, Jan Urbański wrote:
I see two issues with this patch. First of them is the resulting index
size. I created a table with 5 copies of
/usr/share/dict/american-english in it and a gin index on it, using
gin_trgm_
On 2011-01-06 03:10, Robert Haas wrote:
On Wed, Jan 5, 2011 at 3:22 PM, Jesper Krogh wrote:
Given a crash-safe visibility map, what purpuse does the PD_ALL_VISIBLE bit
serve?
If we modify a page on which PD_ALL_VISIBLE isn't set, we don't
attempt to update the visibility map. In th
On 2010-11-30 05:57, Robert Haas wrote:
Last week, I posted a couple of possible designs for making the
visibility map crash-safe, which did not elicit much comment. Since
this is an important prerequisite to index-only scans, I'm trying
again.
The logic seems to be:
* If the visibillity map
On 2010-12-21 21:28, Andres Freund wrote:
On Tuesday 21 December 2010 20:25:16 Jesper Krogh wrote:
What have I missed in the logic?
A reproducible testcase ;-)
Yes, I did a complete dump/restore of the dataset and the numbers
looked like expected. So table bloat seems to be the
Hi Hackers.
I have a feeling that GIN is "cheating" on the visibillity checks:
test=# set enable_seqscan = off;
SET
Time: 0.129 ms
test=# select count(id) from fts_test where fts @@ to_tsquery('core');
count
158827
(1 row)
Time: 95.530 ms
test=# explain select count(id) from fts_test
On 2010-10-23 18:42, Tom Lane wrote:
Jesper Krogh writes:
I have been puzzled about the evaluation order when using window
functions and limit.
It's basically FROM -> WHERE -> window functions -> LIMIT.
I expected it to either count to 3 or blow up and tell
Hi.
I have been puzzled about the evaluation order when using window
functions and limit.
jk=# select * from testtable;
id | value
+---
1 | 1
2 | 2
3 | 3
4 | 4
5 | 5
6 | 6
7 | 7
8 | 8
9 | 9
10 |10
(10 rows)
jk=# select id,count
On 2010-09-22 04:33, Itagaki Takahiro wrote:
On Wed, Sep 22, 2010 at 3:44 AM, Jesper Krogh wrote:
Command to set "tuples_per_page" is:
ALTER TABLE set (tuples_per_page = X)
where 1<= X<= 32.
The tuples_per_page means *minimal* number of tuples in a page, right?
A
Hi.
This is a follow up and updated patch on several old discussions:
http://archives.postgresql.org/pgsql-hackers/2009-07/msg01065.php
http://archives.postgresql.org/pgsql-admin/2010-04/msg00164.php
http://archives.postgresql.org/pgsql-hackers/2009-06/msg00831.php
First patch:
http://archives.po
On 2010-09-17 10:09, Heikki Linnakangas wrote:
I think it makes most sense to set sync vs. async in the master, and
the level of synchronicity in the slave. Although I have sympathy
for the argument that it's simpler if you configure it all from the
master side as well.
Just a comment as a
On 2010-07-15 18:07, Marc G. Fournier wrote:
On Thu, 15 Jul 2010, Thom Brown wrote:
> If it's only a psql problem, why implement it as SQL? Is it just
> so we're not adding keywords specifically to psql? In that case,
> it shouldn't support QUIT.
Personally, I think this is somethign that s
On 2010-07-05 12:11, Pierre C wrote:
> The problem can generally be written as "tuples seeing multiple
> updates in the same transaction"?
>
> I think that every time PostgreSQL is used with an ORM, there is a
> certain amount of multiple updates taking place. I have actually
> been reworking cl
On 2010-07-04 06:11, Tom Lane wrote:
Robert Haas writes:
CREATE OR REPLACE FUNCTION update_tab() RETURNS void AS $$
BEGIN
INSERT INTO tab VALUES (0);
FOR i IN 1..10 LOOP
UPDATE tab SET x = x + 1;
END LOOP;
END
$$ LANGUAGE plpgsql;
I believe
On 2010-06-28 21:24, Kevin Grittner wrote:
Jesper Krogh wrote:
Sorry if I'm asking silly questions, but how does transactions and
connection pooler's interact?
That depends a great deal on the pooler and its configuration, as
well as your client architecture. Our shop
On 2010-06-25 22:44, Robert Haas wrote:
On Fri, Jun 25, 2010 at 3:52 PM, Kevin Grittner
wrote:
Heck, I think an even *more* trivial admission control policy which
limits the number of active database transactions released to
execution might solve a lot of problems.
That wouldn't hav
On 2010-05-31 20:38, Tom Lane wrote:
Jesper Krogh writes:
Just a small follow up. I tried out the patch (or actually a fresh git
checkout) and it now gives very accurate results for both upper and
lower end of the MCE-histogram with a lower cutoff that doesn't
approach 2.
Good.
On 2010-05-31 22:09, Tom Lane wrote:
Jesper Krogh writes:
Conceptually searching for the "full dataset" would always be fastest
solved by a seq-scan. The query planner enforces this so much, so not
even "enable_seqscan=off" can convince it to to something else.
...
Wou
Hi.
The test data a set of generated terms using this perl-script
http://shrek.krogh.cc/~jesper/build-test.pl
and http://shrek.krogh.cc/~jesper/words.txt
I have generated a test dataset with an average tsvector length of
around 250 and 200.000 tuples in the dataset.
Conceptually searching for t
On 2010-05-30 20:02, Jan Urbański wrote:
Here's a patch against recent git, but should apply to 8.4 sources as
well. It would be interesting to measure the memory and time needed to
analyse the table after applying it, because we will be now using a lot
bigger bucket size and I haven't done any p
On 2010-05-29 15:56, Jan Urbański wrote:
On 29/05/10 12:34, Jesper Krogh wrote:
On 2010-05-28 23:47, Jan Urbański wrote:
On 28/05/10 22:22, Tom Lane wrote:
Now I tried to substitute some numbers there, and so assuming the
English language has ~1e6 words H(W) is around 6.5. Let&#
Hi.
There seems to be an "unimplemented" area around getting statistics for
wildcard searches done. Wildcards anchored to the left can be matched
up by the gin-index and the ts_match_vq operator:
testdb=# select to_tsvector('project') @@ to_tsquery('proj:*');
?column?
--
t
(1 row)
Se
On 2010-05-28 04:47, Tom Lane wrote:
Cranking up the stats target actually makes it worse not better, since
low-frequency items are then more likely to get into the MCV list
I should have been more precise in the wording. Cranking up the
stats target gave me overall a "better plan", but tha
On 2010-05-28 23:47, Jan Urbański wrote:
On 28/05/10 22:22, Tom Lane wrote:
The idea that I was toying with is to assume a Zipfian distribution of
the input (with some reasonable parameter), and use that to estimate
what the frequency of the K'th element will be, where K is the target
number
On 27/05/2010, at 20.00, Josh Berkus wrote:
Well, maybe I'm confused here, but arranging things so that we NEVER
have to visit the page after initially writing it seems like it's
setting the bar almost impossibly high.
That is the use case, though. What I've encountered so far at 3
clie
On 27/05/2010, at 02.48, Robert Haas wrote:
On Wed, May 26, 2010 at 8:06 PM, Tom Lane wrote:
Josh Berkus writes:
How does that get us out of reading and writing old pages, though?
Yeah. Neither PD_ALL_VISIBLE nor the visibility map are going to
solve
your problem, because they cannot
On 26/05/2010, at 01.16, Jan Urbański wrote:
On 19/05/10 21:01, Jesper Krogh wrote:
The document base is arount 350.000 documents and
I have set the statistics target on the tsvector column
to 1000 since the 100 seems way of.
So for tsvectors the statistics target means more or less &qu
Hi.
I am working on getting full-text-search to work and have
come across something I think look a bit strange.
The document base is arount 350.000 documents and
I have set the statistics target on the tsvector column
to 1000 since the 100 seems way of.
# ANALYZE verbose reference (document_tsv
On 2010-05-18 18:57, Bruce Momjian wrote:
jes...@krogh.cc wrote:
Hi
I tried running pg_upgrade from the current snapshot of postgresql and
upgrading from 8.4.4 to the snapshot version. Everything seem to look fine
in the process and all that came out was only "ok's" but when I tried a
simpl
On 2010-05-18 23:12, Alex Hunsaker wrote:
set bytea_output 'escape';
That was it. Knowing what the problem was I had no problem finding it in
the release notes.
May I ask whats the reason is for "breaking" the compatibillity?
--
Jesper
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On 2010-05-18 21:56, Bruce Momjian wrote:
Jesper Krogh wrote:
On 2010-05-18 20:52, Bruce Momjian wrote:
This line above looks very odd because I didn't think the template0
datfrozenxid could be advanced. Can I see the output of this query:
SELECT datname, datfroz
Hi.
I'm trying to do a test move of one of our applications onto 9.0beta1.
We use storable and serializes data into a bytea column in the database.
This script uses that:
#!/usr/bin/perl
use strict;
use warnings;
use Storable;
use DBI;
use DBD::Pg;
use Data::Dumper;
my $dbh = DBI->connect("dbi:
On 2010-05-18 20:52, Bruce Momjian wrote:
This line above looks very odd because I didn't think the template0
datfrozenxid could be advanced. Can I see the output of this query:
SELECT datname, datfrozenxid, datallowconn FROM pg_database;
Only from the "old" database:
data=# SELE
On 2010-05-06 06:41, Alvaro Herrera wrote:
Excerpts from Jesper Krogh's message of jue may 06 00:32:09 -0400 2010:
Q: I read you pdf, why isn't statistics copied over? It seems to be the last
part missing from doing an upgrade in a few minutes.
Seems fraught with peril, and a bit poi
On 2010-05-06 01:45, Bruce Momjian wrote:
Jesper Krogh wrote:
On 2010-05-03 23:09, Bruce Momjian wrote:
Robert Haas wrote:
On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine
wrote:
Now you tell me how awful this idea really is :)
I'm not s
On 2010-05-03 23:09, Bruce Momjian wrote:
Robert Haas wrote:
On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine wrote:
Now you tell me how awful this idea really is :)
I'm not sure I can count that high. :-)
While I can't improve on Robert's reply, I can supply a PDF a
Hi.
How complicated would it be to make postgresql-fts search the "union" of
several GIN/Gist indexes.
The use-case is that you have two tables:
tablea(id serial, tableb_id int, text tsvector);
and
tableb(id serial, text tsvector);
and indices on both tsvectors.
The typical query would join the
Tom Lane wrote:
> Jesper Krogh writes:
>> This patch enables users to set TOAST_TUPLES_PER_PAGE with
>> ALTER TABLE SET (tuples_per_page = X); .. currently with 1 <= X
>> <= 32;
>
> It's not clear to me that fiddling with that is useful unless th
public.testtext8| 2552 kB
No documentation on the patch. I'll do that a bit later.
Generally speaking.. if you have some knowledge about the access
patterns of your data then this patch can enable you to teach postgresql
to take advantage of that. In my situation I would estimat
93 matches
Mail list logo
