=?ISO-8859-1?Q?Gunnlaugur_=DE=F3r_Briem?= writes:
> I did this:
> CREATE VIEW unionview AS
> SELECT col, otherstuff FROM (heavy subquery)
> WHERE col BETWEEN 1 AND 3
> UNION ALL
> SELECT col, otherstuff FROM (another heavy subquery)
> WHERE col BETWEEN 4 AND 6;
> hoping that the planne
On Sun, Sep 18, 2011 at 6:14 PM, Craig James wrote:
> Regarding the recent discussion about hash versus B-trees: Here is a trick I
> invented years ago to make hash indexes REALLY fast. It eliminates the need
> for a second disk access to check the data in almost all cases, at the cost
> of an ad
On Wed, Sep 14, 2011 at 6:50 AM, MirrorX wrote:
> any ideas on how i should write to query to use this index? thx in advance
You can do something like:
set enable_seqscan=off;
explain select yourqueryhere;
and see if the plan it comes up with is any better. Use explain
analyze to see how long
On Wed, Sep 14, 2011 at 6:50 AM, MirrorX wrote:
> dear all,
>
> i have a table with (approx) 500.000.000 rows. it has several indexes, one
> of which is a multicolumn index
> for a column that has an id (integer) and a column that has a timestamp. i
> have read in the manual that the multicolumn i
Hi,
I did this:
CREATE VIEW unionview AS
SELECT col, otherstuff FROM (heavy subquery)
WHERE col BETWEEN 1 AND 3
UNION ALL
SELECT col, otherstuff FROM (another heavy subquery)
WHERE col BETWEEN 4 AND 6;
hoping that the planner could use the WHERE conditions (like it would use check
con
dear all,
i have a table with (approx) 500.000.000 rows. it has several indexes, one
of which is a multicolumn index
for a column that has an id (integer) and a column that has a timestamp. i
have read in the manual that the multicolumn index can be used only if the
clauses of the query are in the
On Sun, Sep 18, 2011 at 7:59 AM, Stefan Keller wrote:
> Merlin and Jeff,
>
> General remark again:It's hard for me to imagine that btree is
> superior for all the issues mentioned before. I still believe in hash
> index for primary keys and certain unique constraints where you need
> equality sear
2011/9/19 Ondrej Ivanič :
> BTW, Does Postgres use Bloom filter anywhere?
I saw patches for at least in-memory bloom filters (for hash joins)
Not sure they're committed. I think so.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription
Hi,
On 19 September 2011 11:14, Craig James wrote:
> DBsig for a hash-collision chain is always the bitwise OR of every record in
> that hash-collision chain. When you add a record to the hash table, you do
> a bitwise OR of its signature into the existing DBsig. If you delete a
> record, you e
Regarding the recent discussion about hash versus B-trees: Here is a trick I
invented years ago to make hash indexes REALLY fast. It eliminates the need
for a second disk access to check the data in almost all cases, at the cost of
an additional 32-bit integer in the hash-table data structure.
On 9/18/11 1:18 PM, Stefan Keller wrote:
Hi,
Sorry if this is an odd question:
I assume that Postgres indexes don't store records but only pointers
to the data.
This means, that there is always an additional access needed (real table I/O).
Would an index containing data records make sense?
See
On 18 September 2011 21:18, Stefan Keller wrote:
> Hi,
>
> Sorry if this is an odd question:
> I assume that Postgres indexes don't store records but only pointers
> to the data.
> This means, that there is always an additional access needed (real table I/O).
> Would an index containing data recor
Hi,
Sorry if this is an odd question:
I assume that Postgres indexes don't store records but only pointers
to the data.
This means, that there is always an additional access needed (real table I/O).
Would an index containing data records make sense?
Stefan
--
Sent via pgsql-performance mailing
On 18 September 2011 20:45, Stefan Keller wrote:
> Hi,
>
> I know there exist Bitmap Index Scan and Bitmap Heap Scan in Postgres.
> What about implementing a bitmap index for explicit use (CREATE INDEX ...)?
> Any use cases?
> Bitmap indexes work best on values with low cardinality (categorical
>
Hi,
I know there exist Bitmap Index Scan and Bitmap Heap Scan in Postgres.
What about implementing a bitmap index for explicit use (CREATE INDEX ...)?
Any use cases?
Bitmap indexes work best on values with low cardinality (categorical
data), would be efficient in space and ready for logic operatio
I'm simply referring to literature (like the intro Ramakrishnan & Gehrke).
I just know that Oracle an Mysql actually do have them too and use it
without those current implementation specific restrictions in
Postgres.
IMHO by design Hash Index (e.g. linear hashing) work best when:
1. only equal (=)
Stefan Keller wrote:
> It's hard for me to imagine that btree is superior for all the
> issues mentioned before.
It would be great if you could show a benchmark technique which shows
otherwise.
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make cha
Merlin and Jeff,
General remark again:It's hard for me to imagine that btree is
superior for all the issues mentioned before. I still believe in hash
index for primary keys and certain unique constraints where you need
equality search and don't need ordering or range search.
2011/9/17 Jeff Janes
18 matches
Mail list logo
